>1) Lock up - the machines completely freeze up. CTRL+ALT+DEL does not work. Reset or recycle power only.
That sounds like locked up.
>2) Two of the machines - enter the program, open one form, close it, exit. Enter the program, open one form, freezes. Recycle power only way to get system back up. Windows itself completely freezes up.
OK, something happens when the application closes and then reopens. If you only start the program once, can you operate the program normally for a while, or does the software start to get flakey shortly after the program starts even the first time? And does it consistently lock solid?
How old is the hardware? You mention that you applied SR1 to the machine, which implies original, retail Win95 is on the box. If the behavior were not limited to just this application (IOW, it got flakey after running a while, even a short while, with any software that made the machine work), I'd start checking if the processor or memory were running hot. Pentium chips in particular are prone to overheating, not because of the chip itself, but because of the lousy way most cooling fans are built. I've seen an awful lot of Pentiums where the fan on the heatsink just died; the fan bearing gets gunked up, or the power leads fall off, it stops cooling, and the machine gets flakey over time. This one is easy to check - open the case, look at the Pentium while the power is on, and see if the fan is spinning. If not, you may be able to replace the cooling assembly on the chip with another for $10-15 (if the heatsink is glued on with heatsink compound, just replace the processor and heatsink. Pentium processors are pretty cheap). if I'm going to blame hardware, and the program runs for a while and then things just lock up tight, heat is my first suspect.
Are the two machines that are having the problem roughly equivalent (same or similar motherboard, video card, memory, etc.) as far as hardware and software on them? If you can outline the systems involved in a little more detail, maybe something will jump out at us. In addition to hardware, the operating system revision level and other system software (is IE there? Utilities like First Aid, AV packages, etc? Look at the CONFIG.SYS and AUTOEXEC.BAT, to see if any real-mode drivers are being loaded. SYSTEM.INI and WIN.INI still are applicable to Win9x systems, of particular interest are any LOAD= or RUN= statements in the [windows] section of WIN.INI, and the basic hardware summary listed in [boot.description] in SYSTEM.INI (this has no real effect on what's running, but if the hardware summary doesn't match what you see in place, then a bad driver installation might be an issue.) You can see all the important configuration files other than the registry by running SYSEDIT; it will open up the boot files and several .INIs that are still important to Win9x.
>3) Two of the machines - same location in a peer to peer, are about 300 miles from me. User is somewhat literate but not a hardware or software guru. I guess I will have to make the most of it and try to talk him through hardware tests.
Are these the only machines on the network, or are there machines that that are operating correctly? How much 'stuff' is loaded on these machines (IOW, if it were necessary to reinstall Windows from scratch to clean up the environment, how long would it take to get them back up and running with their existing software. One of the standard things to say here is 'Reinstall Windows', and in this particular case, I'd try to go with a more recent release of Win95 (like one of the OSR2 releases, or Win98), especially if they have IE 4 installed, and particularly if they are using Active Desktop. Unfortunately, there's no official upgrade path from retail Win95 to OSR 2.x; it usually requires a fresh install, or at a minimum, blowing away some files in the \WINDOWS directory and a fresh install of OSR2 which may screw up the registry. If the hardware is up to it, and the customer already has (or is willing to purchase) Win98, you can upgrade that way, but you'd be much better off starting fresh.
>4) Anti-virus is running - I had him try it without the software running. Failed.
If the machine is infected, AV software might not pick it up. Download a fresh copy of McAffee, or FRISK from your site, make a DOS (well, Win95 DOS) boot disk, put the command line AV software on it, and write-protect the floppy. have them boot from the (known clean) floppy and run the AV software on their machine. Don't run anything off their drive until after you've checked the system. It's unlikely, but possible, and there are too many people who assume that they're safe because the AV software was loaded. If the AV stuff isn't run from a clean environment, the testing is suspect.
>5) Had him restart - fire up windows w/o the network. Same failure.
What about in Safe Mode? Another easy test to see if it's something related to the registry settings or drivers - if it runs in Safe Mode, then something is getting loaded during the boot process that's causing the problem.
>6) Latest Video drivers installed.
Great. How about generic drivers rather than the board-specific driver? Switch temporarily to the Standard VGA or SVGA driver rather than the manufacturer's driver. This is another easy test, and if both machines are using the same video board, a common factor that you can switch out of the mix.
>7) Windows 75 sp1 applied.
Bletch. Retail Win95, even updated to SR1, has lots of bugs; there are dozzens of patches that came out after SR1's release. I think OSR 2 is up to at least version 2.5 now. And there are probably patch to that by now - it's been out for a couple of months.
>8) Dcom updated.
Nothing you've listed here indicates a DCOM problem - the machine isn't giving you a C0000005 during application shutdown, and the DCOM-related C0000005 failure doesn't lock up the system; it only faults the program during shutdown.
>
>I am real interested how others would go about this. Do we take a trip and work on site? Do we attempt to walk them through? In May, I could have him bring one of the machines to me during our convention. Should I get MS involved with my last tech support call? I guess no matter what - it is not going to be easy...
It depends on your relationship with them. If you've got a spare box at your site where the software works now, I'd drag that out to their site, add a NIC, and see if it breaks. If it doesn't, and you can afford to leave the machine in place at the client site, take one of the machines that doesn't work back to your office to test things. Trying to do detailed testing at a client site is tough enough where you have an idea about what the problem might be (I hate having people standing over me anyway), and being able to drop in another machine and have it work immediately will build a bit of confidence (see, it's something in your hardware or software, so the problem is fixable) and good will (we think you're important - let us leave you with something that works while we figure out how to fix your system.) If you've got to go on-site to troubleshoot things, maximize your chance of leaving with something running properly there.
If they'll just send one of the malfunctioning systems down to you to test, without having to go on site, so much the better.
You've probably got better resources in your office than at their site, and you can do things at a more leisurely pace without someone breathing down your neck. If they're worried about what you might do to their machine, you can do things like swap out their drive, put in a fresh one, do a fresh install of Windows and your software and see if the problems disappear. If they do, you can now show them that the problem is somewhere in their software configuration, and they'll react less violently to a reinstall from scratch approach to fixing things. If you try a reinstall of Windows on their site and it doesn't work, you've wasted a lot of time in front of them.
>>
>>You're going to get lots of guesses, any one (or more) of which may be right. I think a better approach is to clarify exactly what you mean by 'lock up', and from the symptoms, see if we can find common elements of the two machines that fail that are different on others that don't.
>>
>>Let's clarify 'lock up'. What does the program do - does it load at all, does it run for a while and freeze, does it fail to respond after some specific sequence of actions, or some period of time. I'd like to nail down the concept of the error with greater precision than President Clinton used to define what he and Monica did as not being sexual relations...
>>
>>Next, look for some common components of the system that lock up. Start with hardware - processor, motherboard revision, video card, memory. Once you found some things that look common to both, see if you can find other systems that have the same configuration items and don't lock up.
>>
>>Next, software. this is the most tedious of tasks, and the one most likely to be the root of your problem. Examine the entire environment - you need to examine the operating system, including patches applied, drivers and driver revisions, network configuration and the like. Then start looking at components like software found on the systems that lock up but not on the others. This requires that you examine exact versions of software; it could be as simple as a common patch to a package not otherwise suspect (I saw this recently when a few things broke when applying the initial SR2 for Office, not caused by the SR2a patch. Outwardly, both SR2 versions identified themselves as the same revision level; we had to examine common components version and sizes to find out exactly what needed to be changes to make a station with Sr2 on it behave like it had SR2a, since the SR2a install didn't run if SR2 was already in place. This is a long and boring story...)
>>
>>You've checked for virii already, I presume.
>>
>>If nothing seems to come out of detailed analysis, try to simplify and standardize the systems' configuration. Turn of APM. Under Win98, try using MSCONFIG to adjust what drivers are loaded, and to block sections of the registry, SYSTEM.INI, WIN.INI, AUTOEXEC.BAT and CONFIG.SYS temporarily. MSCONFIG is a wonderful troubleshooting tool where base driver loading and configuration issues may be the root of a problem.
>>
>>You've already run extensive diagnostics to make sure the hardware is OK, right?
>>
>>If other, similar systems are working, you might want to take a look at items in the CMOS setup. A little injudicious tweaking of memory timing, disk modes and the like might be causing your problems.
>>
>>Do the basic homework, clarify the exact symptoms and conditions of contest, and we stand a better chance of guessing the cause of your problems...
