0

A user has sent me an APPCRASH program exception. It states that the c0000005 error occurs at offset 0008dc7b, specifying my DLL.

I run the exact same release version on my PC, hit a breakpoint, open the disassembly window where I can see the assembler and my code. I then enter the address 0x0008dc7b. Unfortunately it just comes up with ????. Any idea where I am going wrong? The user PC is running on Japanese Windows.

The exception log, with Japanese translated to English

Problem signature: Problem Event Name: APPCRASH

Application Name: Winspm_ScanFunction.exe

Application Version: 6.0.3.17

Appplication Timestamp: 5991e458

SPM_ScanFunction.dll

Fault Module Name: 6.0.3.17

Fault Module Timestamp: 5991e3ea

Exception Code: c0000005

Exception Offset: 0017d264

OS Version: 6.1.7601.2.1.0.256.48

Locale ID: 1041

Additional Information 1: 0a9e

Additional Information 2: 0a9e372d3b4ad19135b953a78882e789

Additional Information 3: 0a9e

Additional Information 1: 0a9e372d3b4ad19135b953a78882e789

http://go.microsoft.com/fwlink/?linkid=104288&clcid=0x0411

C:\windows\system32\ja-JP\erofflps.txt

drb01
  • 189
  • 1
  • 2
  • 17

1 Answers1

1

Are you sure 0008dc7b is the offset or is it the virtual address in your program.

Amit Rastogi
  • 926
  • 2
  • 12
  • 22
  • I have no idea I'm afraid. I just put the exception address 0x0008dc7b in the address bar of the disassembly window. I did a test run by forcing an exception on my PC and it worked fine. I have added the exception log, with the Japanese translated to English, to the original post – drb01 Aug 22 '17 at 13:53
  • 1
    Would it be possible for you to ask your user to generate the dump (.dmp file) file when this exception occurs. In case you are able to get the .dmp file you can analyze it with the help of the symbol files (pdb files) of your executable and dll binaries using Windbg. This would give you the location of the access violation exception. – Amit Rastogi Aug 22 '17 at 15:15
  • 1
    You can ask your user to collect the dump using Windows Error Reporting (WER). You can refer to this link for more details-https://msdn.microsoft.com/en-us/library/windows/desktop/bb787181(v=vs.85).aspx – Amit Rastogi Aug 22 '17 at 15:23
  • Is that the dump file generated by Task Manager? I can get that. But any idea why the exception offset I was given doesn't work? It says it occurred in my DLL.. I did send a few minutes trying to analyse a dmp file on my pc here without success as it didn't seem to have an exception address.. But I can work that out – drb01 Aug 22 '17 at 15:24
  • 1
    Yes you can use taskmgr as well to collect the dumps. Regarding your question on exception offset you would need to add the offset to the DLL load address under Visual Studio and then use this calculated address in the disassembler address field (use 0x prefix). I think you were not adding the DLL base address that's why it was not working. But to find the root cause of the access violation you would need the dumps. Check this stackoverflow post for more details - https://stackoverflow.com/questions/2528776/windows-c-is-it-possible-to-find-the-line-of-code-where-exception-was-thrown – Amit Rastogi Aug 22 '17 at 16:07
  • it appears the exception occurred in va_list, but I need more info so I'm trying to get minidump to work. I caused an exception on my PC, then Task Manager->Create Dump. I copied the DLL and PDB to the DMP directory, loaded VS2015, and loaded the DMP. VS lists the modules, and says "Exception Code not found" among other things. Debug>Start Debugging is disabled. I then run "Set symbol paths" and then (as Start Debugging is disabled) I clicked on "Debug with Native Only". It says "The application is in break mode". After a few hours I have made no progress. Any idea where I am going wrong? – drb01 Aug 23 '17 at 16:32
  • Check this out in case you are missing anything https://msdn.microsoft.com/en-IN/library/d5zhxt22.aspx. As an other option can you use windbg? Just load the dmp file specify the symbol and source file path and just specify !analyze -v command. This would give you detailed info about the exception. Check the link for more windbg commands http://windbg.info/doc/1-common-cmds.html – Amit Rastogi Aug 23 '17 at 17:52
  • If I run the application in VS2015, and use Save Dump in VS2015, then everything works amazingly well in both VS and WinDBG. But if I use Task Manager to create the dump then nothing works. It doesn't even state the Exception Code which is "Not found". I put the DLL and PDB in the same directory as the DMP file. FWIW it is an old 32 bit MFC application, and the application has the same filename as the DLL... – drb01 Aug 23 '17 at 19:12
  • It might be possible that the symbols might not be loaded correctly when your are using the task manager dump file. Can you try using NT_SYMBOL_PATH environment variable to specify the symbol file path. Check this link for details https://msdn.microsoft.com/en-us/library/dd255404.aspx . Also, are you using 64-bit Windows? In case of 64-bit Windows you should generate the dump of 32-bit application using the 32-bit task manager (in Windows\SysWOW64) to generate proper 32-bit dump. – Amit Rastogi Aug 23 '17 at 19:49
  • Still no luck! I created the dump from 32 bit Task Manager. In a CMD window I put "set _NT_SYMBOL_PATH=srv*C:\symbols*http://msdl.microsoft.com/downloads/symbols*c:\users\robert\appdata\local\temp". The DLL, PDB & DMP are all in the same directory. I then ran VS2015 from the CMD window. It made no difference. I still don't understand why when I open the dump file it says "Exception Code .. not found" although it says Heap Info is Present. The dump files created by VS showed an exception code... Apologies this is dragging on, and thank you vm for your help! – drb01 Aug 23 '17 at 21:48
  • Please take the dump using Process Explorer. It has the option of taking both minidump and fulldump. You can check in both the dumps. It appears to me that the mindump from task manager might not be having the exception context. You can download Process Explorer from https://learn.microsoft.com/en-us/sysinternals/downloads/process-explorer – Amit Rastogi Aug 23 '17 at 21:54
  • Still not working. The Module Window says all symbols are loaded. But the Exception Code is still "not found", although the Process Name and directory are correct. If I click "Debug with Native only" then it just says "The application is in break mode". have tried with and without the .sln loaded... So close yet so far! I – drb01 Aug 23 '17 at 23:48
  • I have now created a completely new win32 application, and installed VS2017. I get the same. "Exception code not found" when I load the dump from task manager 32 bit. – drb01 Aug 24 '17 at 08:50
  • 1
    Your exception was reported in a DLL right? Did you add the exception offset to the DLL base address (check in Debug -> Windows ->Modules for the DLL base address) and then use this calculated address in the disassembler address field (use 0x prefix)? Please read this link for the details- https://stackoverflow.com/questions/2528776/windows-c-is-it-possible-to-find-the-line-of-code-where-exception-was-thrown – Amit Rastogi Aug 24 '17 at 09:07
  • yes. That worked with the user supplied Windows Problem Signature, and the exception seems to have occurred in va_start.. But I need more information so I want to get the user to send me a minidump. I am just trying to get a minidump to work on my PC before I trouble the end user.. Hence the problem - the minidump wont work on my Win10 64bt PC (which is 2 weeks old) – drb01 Aug 24 '17 at 10:03
  • 1
    Can you try analyzing your local minidump using Windbg as I had mentioned in one of my previous comments? – Amit Rastogi Aug 24 '17 at 10:59
  • I have done that all along. It is the same... It works well with a dump saved from VS, but is unhelpful with dumps from task manager etc.. – drb01 Aug 24 '17 at 12:22
  • I personally prefer using Windbg for dump analysis rather than Visual Studio. Its more powerful. Check this stackoverflow post -https://stackoverflow.com/questions/105130/why-use-windbg-vs-the-visual-studio-vs-debugger – Amit Rastogi Aug 24 '17 at 14:43
  • Well, the original problem of getting the Exception Offset is now working with the DLL offset - thank you very much! TBH I have no idea how my end user even got hold of the ProblemSignature.txt in the first place as I can't find one on my PC. Regarding the task manager, I may start a new thread appropriately titled as it is a slightly different problem to this original question.. – drb01 Aug 24 '17 at 15:53