It is possible to know the line where an application faulted even if it was not running under debugger or memory dump is not available. It won’t probably tell you why it failed, but it will give you at least a point where to start investigating.
After the application failed, look at the Windows Event Logs for an entry like this:
"Faulting application yourapp.exe, version 18.104.22.168, time stamp 0x49e0238, faulting module yourmodule.dll, version 22.214.171.124, time stamp 0x09ec5a57, exception code 0xc0000005, fault offset 0x000000000051000e, process id 0x00, application start time 0x00."
- Load the module that faulted using windbg.exe -z c:\yourmodule.dll (make sure you have symbols!)
- List the modules loaded (yourmodule.dll in this case)
start end module name
00000000`00300000 00000000`00425000 yourmodule (private pdb symbols) c:\yourmodule.pdb
- Find the line where it crashed by adding the ‘fault offset’ reported in the event viewer to the ‘start’ address of your module
0:000> ln 300000+5100e
If your symbols don’t match exactly the module that is in production, you can try in windbg the command ‘.symopt +0x40’; it will make it less restrictive.