CODEWITHSUNDEEP
c#.net-4.0windbgaccess-violation
Simsons
Simsons

Reputation: 12745

How to use Debugging information from WinDbg

My application is crashing constantly while I was trying run it from the release folder.

I put logs inside try catch blocks and capture them but they all pointed to one method. The deatiled problem is in my previous post.

Then I decided to use WinDbg and attach the executable to check what exactly is crashing my application. Now the info from WinDbg seems cryptic.

(13e4.1444): Access violation - code c0000005 (first chance) First chance exceptions are reported before any exception handling. This exception may be expected and handled. *** ERROR: Symbol file could not be found. Defaulted to export symbols for E:\VCS\DeskconWSP\Deskcon\bin\Release\tinyWRAP.dll - eax=0e7e1c00 ebx=0d83d918 ecx=0d835b70 edx=0cce8ce0 esi=0d835b70 edi=ffffffff eip=00000000 esp=0e4dfa4c ebp=0e4dfa58 iopl=0 nv up ei pl nz na po nc cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00010202 00000000 ?? ???

Any reference or pointers on how to use this debug info?

Upvotes: 0

Views: 773

Answers (1)

hythlodayr
hythlodayr

Reputation: 2387

  1. I mean this in the best way possible, but you need to read-up on WinDbg (see WinDbg A-Z). It has a huge learning curve, but it's really useful once you get used to it.

  2. You need to configure WinDbg to load in the debug information for tinyWRAP.dll. There should be a file called tinyWRAP.PDB, assuming you're the developer for this file. Open File->Symbol Path and add as needed.

  3. Microsoft supports a symbolserver (i.e., PDB files) for their own binaries. Add this "path" to the WinDbg symbol server path and WinDbg will download whatever it can find from MS: SRV*C:\SymbolServer\symserver*http://msdl.microsoft.com/download/symbols

  4. Access violation just means the program is trying to access heap memory that is shouldn't; i.e., memory allocated for another process.

e.g., if you're doing arithmetic on a pointer to an integer without dereferencing it first, you'll end up pointing the variable to some other location which the process may not have access to.

You'll almost never see this in a purely managed program, but if you're interacting with native DLLs or code then this may give you a hint of what's going on.

Upvotes: 4

Related Questions