aoccdrnig to a rscheearch at an Elingsh uinervtisy, it deosn't mttaer in waht oredr the ltteers in a wrod are, the olny iprmoetnt tihng is taht frist and lsat ltteer is at the rghit pclae. The rset can be a toatl mses and you can sitll raed it wouthit porbelm. Tihs is bcuseae we do not raed ervey lteter by it slef but the wrod as a wlohe.

One night when I had to stay here WAY too late to find a crash in a release build -- I found an MSDN article from way back that describes how to find the crash address in a release build, and relate that to a line of source code! Pretty cool.

So I investigated this technique, and have proven to myself that it works. It requires a couple things be done to the release builds, so I'm passing this along to you in other projects in case you want to do this too. I put a NULL pointer crash in a project, built and took to Win98 in the lab, got the crash, then found the source. (see pic below)

The article is too old to be found on the web any more, but search for "crashfinder bugslaying rebase" in MSDN help on your machine. John Robbins (author) has written a tool that uses your release binary, along with the debug information stored in a separate PDB file, and looks up the address of the crash -- relating it to the line of source code.

The two things that are critical in this process:
you MUST rebase your DLLs to a unique load address. This is the only way the hex address reported at crash time will make any sense to the tool. If your DLL gets dynamically relocated by the loader, the tool has no idea where to lookup the address.
you MUST create debug info files for your release builds.

The second item sounds a little weird. But it's true, you can create debug info for release builds. The debug info is created in a separate PDB file, which relates lines of source code to instructions in the release binary. This is the critical step: you must keep the debug info PDB files that relate to the release binaries. So when you use the CrashFinder tool, you load the release DLL, the debug info PDB, and enter the source address.

You do not ship the debug info PDB files, and this process only adds 1 KB to the release binaries (to inject the pdb file info into the header of the binary).

So....if you're interested, you need to make the following changes to your project settings for Release builds:
C/C++ tab, General Category, Debug Info == "Program Database"
Link tab, General Category, select "Generate Debug Info"
Link tab, Debug Category, make sure "Debug Info" is checked, and "Microsoft Format"
Link tab, Project Options edit box, manually type " /opt:ref" in the edit box. (this step is not described in the article, but documented on his website. without this, functions that are not referenced are still included in the binary, making in MUCH larger)

Crash Finder (MSDN)

Example of .INF file in a cab for IE download:
[version]
signature="$CHICAGO$"
AdvancedINF=2.0

[DefaultInstall]
;AddReg=MotivePreQualReg
CopyFiles=MotivePreQualFiles
RegisterOCXs=RegisterControlSection

[DefaultUninstall]
DelReg=MotivePreQualReg
DelFiles=MotivePreQualFiles
UnRegisterOCXs=UnRegisterControlSection

[MotivePreQualReg]
;HKLM,Software\Motive,PluginHostUrls,,http://sicilian.motive.com/PreQualifier.html|file://D:\Telco\Components\Phase_I\MotivePreQual\PreQualifier.html

[MotivePreQualFiles]
MotivePreQual.dll,,,,11
MCCDevice.DLL,,,,11
MCC16.DLL,,,,11

[RegisterControlSection]
%11%\MotivePreQual.dll

[UnRegisterControlSection]
%11%\MotivePreQual.dll

[inffile]
MotivePreQual.inf,,,,33

[DestinationDirs]
MotivePreQualFiles=11
inffile=17

[MotivePreQual.dll]
file-win32-x86=thiscab
clsid={C606BA60-AB76-48B6-96A7-2C4D5C386F70}
FileVersion=1,0,0,2
DestDir=11
RegisterServer=yes

BBC Persian

Event from out of process COM server

285874 - HOWTO: Retrieve XML Data Asynchronously with ondataavailable Event