This month’s bug story is a slow pitch, just in time for baseball season. There comes a time in your practice where you find your application works on most machines, but not all. And of course, your customers or users will tell you their machine is “exactly” like his neighbors where your code is working fine. Are the machines really the same? I know in my career I have had two extreme cases of “similarity” gone wrong. One was back in the NT 4.0 days, where I had two industrial computers, one that frequently blue screened, while the other did not. Same rugged box, same motherboard, same OS load, same app. It turned out the bad box had a pair of generic memory chips, whereas the good box had a recognizable name brand. Sadly it took weeks and weeks and several go-arounds with the box vendor to finally figure this out. I had another situation where we were installing eight different single board PC-104 computers into the racks at a NASA research lab. Three of them just would not behave. With a tight timescale working late into the night, we had to figure out fast what was “different” about these “same” computers ASAP. In a rare flash of insight, I looked at the BIOS versions. It turns out the three PC-104 boards had older BIOSs. Flash the new BIOS, and all three boards came up singing in harmony.
Just this week, we’ve been tackling a similar sort of situation. Machines of same grade and supposedly installed set of components work some places, not others. We have in the DevPartner Studio and DevPartner VC++ kits a tool called System Comparison, which you’d think would be just the widget to isolate what was “different” about these machines. Out of the box, System Comparison does a reasonably deep inspection of common Windows-ish areas: drivers, Win32 services, system executable file and DLL versions, .NET and Java framework details, environment variables, and some hardware facts. To really make System Comparison useful for our team we want to also know about the details of Visual Studio versions installed, both in terms of files and features deployed, as well as registry keys and values. To inspect these “application differences”, we trained System Comparison to accept the top level folders and registry hives for all the versions of Visual Studio we care about, being sure to select all subfolders and subhives to pickup all details down to leaf levels. The extra customization involved adding a handful of text strings to a pair of XML config files, so certainly not a difficult task if you know the basic aspects of your application, like install directory, common files directory, and top of registry hive. In our situation the smoking gun was revealed: one of the components came from the wrong code branch, not the active stream under development and test, with DLL version “999” the dead giveaway.
You can customize which paths or sections to collect for your own applications of interest by editing the files FileSections.xml and RegistrySections.xml, respectively, both located under the data subdirectory in the System Comparison installation folder. Put System Comparison, or just its Snapshot SDK that does not require a license checkout, onto your target machines, apply the tailored File and Registry additions for your app, and bring back any snapshots for differencing analysis. Hopefully you can nail your application deployment differences using this “very same”, or at least a “somewhat similar”, technique with only “minor differences.”
If you want to see proper syntax for editing these files, or need help applying them to your situation, start a topic under the DevPartner Community Forum entitled "SysComp Application Differencing--MyApp." I'll try to offer tips for your situation.