An Incoming Request for Troubleshooting Advice

I recently received the following via email. I responded, but never heard back. Hopefully the information will be of use to others...

Hi, Found your name on the web when I was looking at some stuff on slashdot and I thought maybe you might have a moment to point me in the right direction.
I have a custom app which I have zero access to in terms of the developer. When the app was run on new hardware, a few users would periodically get a bizarre error, but never on their old hardware. Main difference seems to be core 2 duo on the new laptops.
Anyway, this error causes a total reset of the internal windows database system used by the app and then there's an error in msvcr80.dll. Is there a way I can tell from the data below what routine went bad in that module? I could at least then tell the guy who guards the gates to tell the developer a little bit more. At this point the "guard" is convinced it is just because the dll is not the latest version. I think it is probably not that simple.

[app].exe signature
Appname [app].exe App. Ver.
Mod Name: msvcr80.dll
Mod Ver: 8.0.50215.44
Offsett: 000161fd

Error report contents
Exception info:
Code 0x0000005
Flag 0x00000000
Record 0x000000000000000
Address: 0x000000007C3861fd

I responded with the following:

It does appear that the problem may lie in the version of MSVCR80.DLL you referenced. At least, getting this to an appropriate version seems like a very reasonable first step towards troubleshooting.

According to a dude on the VC++ compiler team (Jonathan Caves @ http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=164465&SiteID=1&PageID=1 ), version 8.0.50215.44 of MSVCR80.DLL "is not an officially released version"; he links to this site (http://www.dll-files.com/dllindex/dll-files.shtml?msvcr80 ), which has a statement by another member of the VC++ team (Martyn Lovell):

"a) This is the beta 2 version of msvcr80.dll. Don\'t install it. b) This file should never be installed in system32 (except on Win9x and Windows 2000). c) The .NET framework already installs the copy correctly (in WinSxS). d) The correct source for an msvcr80 binary is from your application provider, not from this site. Martyn"

The MS DLLHelp Database entries for MSVCR80.DLL (http://support.microsoft.com/dllhelp/?dlltype=file&l=55&alpha=msvcr80.dll&S=1 ) indicate that you can get the DLL from "MS SQL 2005 Server Enterprise" or "Microsoft Visual Studio 2005 Professional". Martyn from Microsoft indicates that you should get this DLL from the application provider. He also stated that you can get it as part of the .NET Framework redistributable (version 2.0). It also appears that you can get it as a part of a package from the "Microsoft Visual C++ 2005 SP1 Redistributable Package (x86)" at http://www.microsoft.com/downloads/details.aspx?FamilyID=200B2FD9-AE1A-4A14-984D-389C36F85647&displaylang=en.

FWIW, 0x0000005 is not a valid exception code, though I suspect you meant 0xc0000005, which is the code for an access violation. You're reporting a crash at address 0x7C3861fd. With no other info it is difficult to determine what is loaded at that address (especially since the "shipping" / non-beta versions of MSVCR80.DLL are based at 0x78130000 with a virtual size of 0x9b000), but it seems likely that the beta version of MSVCR80.dll has a different base address (0x7C370000) / size which could/should include the crash address (or, the DLL could have been rebased by the loader).

I suspect that a "Dr. Watson" or "Windows Error Reporting" dump file may have been created from the application crash(es) - these are files with a .dmp extension, and they contain information useful for debugging, or getting more information about, these kinds of problems.

Hope this helps you!



Deep Understanding?

I was reading a recent blog entry by Eric Sink, and he made some comments that I thought I would take the time to share. Nothing profound on my end, mind you... ;)

In "In defense of Petzold's WPF book", the founder of SourceGear writes about a recent trend in books and tools for developers that focus on "quick results", and the trade off that goes along with this trend - loss of "deep understanding". I too have noticed this in working with various developers. While it is admirable that one is able to produce results quickly and ship a product in record time, or add some features in the blink of an eye, it seems that much of the productivity is lost when problems crop up - problems that are at least partially a lack of - you guessed it - deep understanding. As I'm one who likes to have Deep Understanding, I'm probably biased. That said, I can fully appreciate Eric's statement that "When I hire a software developer, I look for deep understanding". I think that it is important to understand how something works so you are able to use it as effectively as possible. Perhaps this is why I am inclined to consider writing software an art, as opposed to a means to an end. Sure, it's both, but how you treat it can have a significant impact on the quality of the end product. At least, that's been my experience.

To me, Deep Understanding implies passion - if one takes the time to understand something fully, to explore all venues of a topic or a technology, they truly care about what it is they're doing and are excited by it. And I can't see doing something as a profession and not being passionate about it.