windbg Windows 7 64-Bit / Visual Studio 2010 Ultimate

[ahoodin]

Can somebody weigh in here and tell me if they have experienced this?

Also please tell me what exactly they experience with VS2010 Ultimate
and Windbg.

I have a laptop I am supposed to be using to debug crash dumps.

windbg is not acting correctly. I decided to do a test and tried to just
debug a program, and although I can set a breakpoint, the debugger
does not stop on the breakpoint.

I know there is a problem with the Visual Studio 2010 runtime libraries and
windbg x64 / Windows SDK on Windows 7. The developer who gave me the
laptop said the development environment and windbg were installed correctly.

I doubt it.

Please give me a frame of reference here.

Thanks!

[Alex F]

"windbg is not acting correctly" - not too much informative. Did you set source, exe and .pdb directories in WinDbg? Is the program built with debug information? Do you have .pdb and source files on the computer? Do these .pdb files match the executable file? Did you enable Microsoft symbol server? Are you talking about kernel or user mode crash dumps?

[ahoodin]

"windbg is not acting correctly" - not too much informative.

Sorry, When I run analyze -v the debugger is not coming up with address or the line of code with with the problem. In order to see whether my debugger was malfunctioning, I created a simple project with my compiler and attempted to step through it. I could place a breakpoint but windbg would not break.

"Did you set source, exe and .pdb directories in WinDbg? Is the program built with debug information?

Yes. Yes

Do you have .pdb and source files on the computer? Do these .pdb files match the executable file?

Yes

Did you enable Microsoft symbol server? Are you talking about kernel or user mode crash dumps?

Yes, in order to get the symbol server, I had to get the laptop internet access. The network settings were old, so originally it would not connect to the internet.

They are User Mode crash dumps. No device driver debugging going on here.

[Alex F]

There are many small details in post mortem debugging. First, how dump file is created? If you use MiniDumpWriteDump, dump type should be at least MiniDumpNormal for native application. Assuming that dump is OK, I suggest you to make the following tests:

1. Build the program on developer computer with Visual Studio, reproduce the crash and open crash dump in Visual Studio. This is easy, because Visual Studio debugger knows where is .exe, .pdb and source files. Usually such crush dump works without any efforts. Do the same with WinDbg.

2. Reproduce the crash on another computer, take the dump to the same computer where .exe was built, and open it with Visual Studio. At this stage you need Microsoft debugging symbols, because Windows where the program crashed may be different than Windows on developer computer. Note that .pdb files should be from the same build, and not just rebuilt from the same source.
During this debugging session, look at the Output window: all executable files (exe and dll) should be loaded with debugging symbols. If not - you have a problem.

3. Once Visual studio debugger works, try to do the same with WinDbg.

4. Take crash dump to another computer with Visual Studio (not the one where .exe was built). Open crash dump with Visual Studio.Now you need to have .exe, source and .pdb files available + Microsoft symbol server. Does it work?

4. Try WinDbg now.

5. Now make the same on your laptop, which only has WinDbg.