Solved Unable to load dmp files for some users, any ideas why?

[writhziden]

I am unable to load the dmp files for whomeno in http://www.sevenforums.com/crashes-debugging/205012-nvlddmkm-sys-bsod-geforce-7600gt.html

I have experienced this a couple times. This is what I get in WinDbg:

Microsoft (R) Windows Debugger Version 6.12.0002.633 AMD64
Copyright (c) Microsoft Corporation. All rights reserved.


Loading Dump File [C:\Users\Mike\Downloads\BSODDmpFiles\whomeno\Windows_NT6_BSOD_jcgriff2\122711-25718-01.dmp]
Mini Kernel Dump File: Only registers and stack trace are available

Symbol search path is: SRV*c:\users\mike\documents\symbols*http://msdl.microsoft.com/download/symbols
Executable search path is: 
Windows 7 Kernel Version 7601 (Service Pack 1) MP (2 procs) Free x86 compatible
Product: WinNt, suite: TerminalServer SingleUserTS
Built by: 7601.17640.x86fre.win7sp1_gdr.110622-1506
Machine Name:
Kernel base = 0x82844000 PsLoadedModuleList = 0x8298d4f0
Debug session time: Tue Dec 27 13:11:23.352 2011 (UTC - 7:00)
System Uptime: 0 days 4:08:03.368
Loading Kernel Symbols
...............................................................
................................................................
............................
Loading User Symbols
Loading unloaded module list
........

And then it just stops

I could load two of his dmp files, and I can load 95% of dmp files of other users, but occasionally I get the above problem.

 

[Anak]

Possibly your ISP, Microsoft's server's are busy? What version are you running?

 

[writhziden]

6.12.0002.633

I've actually had this problem all day, so it is unlikely due to Microsoft's servers being busy.

 

[Anak]

I am running 6.11.0001.404. It takes a few seconds, but finishes the analyze search in about 15seconds.

Has it been happening "just today", and not before today?
If you are on wifi, anything different there?
Any pets in the back of your setup? check wires.

I just tried opening whomeno's reports, and they took about 15sec. for each one.

A little off topic...
I have been meaning to ask someone, and it looks like your "it".
because I have not been able to find this answer.

Do I need to uninstall my 6.11 to do upgrades?

 

[writhziden]

I am running 6.11.0001.404. It takes a few seconds, but finishes the analyze search in about 15seconds.

Has it been happening "just today", and not before today?
If you are on wifi, anything different there?
Any pets in the back of your setup? check wires.

I just tried opening whomeno's reports, and they took about 15sec. for each one.

A little off topic...
I have been meaning to ask someone, and it looks like your "it".
because I have not been able to find this answer.

Do I need to uninstall my 6.11 to do upgrades?

I don't know what is required to upgrade windbg. I should look into it, as well, or maybe I should downgrade? lol I left mine on for a minute with those files, and it still did not load. whomeno's are the only ones I've had issues with today. I've opened I'd guess 20-30 dmp files today just fine.

 

[Anak]

The only thing I can think of for now is whomeno's zip program is corrupted somehow or it does not meet standard practices, and once un-zipped become hard to impossible for the dbg to read. Thus causing the impasse when dbg submits them.

I am going to send a VM to John King, usamma or jcgriff about the updating, and see what they say.
I will let you know.

 

[writhziden]

The only thing I can think of for now is whomeno's zip program is corrupted somehow or it does not meet standard practices, and once un-zipped become hard to impossible for the dbg to read. Thus causing the impasse when dbg submits them.

I am going to send a VM to John King, usamma or jcgriff about the updating, and see what they say.
I will let you know.

Thanks Anak. Appreciate the help.

 

[Anak]

Your welcome writhziden.

I did check with zigzag, and he tells me it is okay to install the dbg overtop an old install, as long as it is the same bits (32 or 64).

 

[writhziden]

I found a solution to the problem. If it gets stuck as it did in my case, click Debug -> Break -> then click on the command line box (next to kd>) -> Type "!analyze -v" (without quotes) -> Hit Enter

 

[Anak]

Good to know!

Your thread may turn into a "sticky". "Debugging the debugger"

 

[writhziden]

Good to know!

Your thread may turn into a "sticky". "Debugging the debugger"

The WinDbg problem seems to occur when it cannot properly verify all driver dates. One of the times that I used the Break trick, it spit out about 20 drivers that were unable to have the dates verified. My guess is: the data for the dates gets corrupted and WinDbg can't verify them properly.

 

[Anak]

I wonder how long one would have to wait for Microsoft to verify your theory.

 

[writhziden]

I wonder how long one would have to wait for Microsoft to verify your theory.

I don't know, but I'm not paying them to figure it out. Lol. My dad was writing a piece of software and found an issue with Microsoft's code, and they wanted him to pay them the troubleshooting fee just for him to tell them what it was. Microsoft is just a money sink hole when it comes to their programs having issues that need fixing.

Edit: I have sent an e-mail to the SDK team to see if they can find the problem. I attached a sample .dmp file that I had issues with.

 

[Anak]

I wonder how long one would have to wait for Microsoft to verify your theory.

I don't know, but I'm not paying them to figure it out. Lol. My dad was writing a piece of software and found an issue with Microsoft's code, and they wanted him to pay them the troubleshooting fee just for him to tell them what it was. Microsoft is just a money sink hole when it comes to their programs having issues that need fixing.

Well, that only seems fair.
There are several sayings that come to mind...One is; "What goes around, comes around"

Edit: I have sent an e-mail to the SDK team to see if they can find the problem. I attached a sample .dmp file that I had issues with.

Did you send it through a proxy, you would not want them to know your IP address.

 

[writhziden]

I wonder how long one would have to wait for Microsoft to verify your theory.

I don't know, but I'm not paying them to figure it out. Lol. My dad was writing a piece of software and found an issue with Microsoft's code, and they wanted him to pay them the troubleshooting fee just for him to tell them what it was. Microsoft is just a money sink hole when it comes to their programs having issues that need fixing.

Well, that only seems fair.
There are several sayings that come to mind...One is; "What goes around, comes around"

Edit: I have sent an e-mail to the SDK team to see if they can find the problem. I attached a sample .dmp file that I had issues with.

Did you send it through a proxy, you would not want them to know your IP address.

The SDK team never did respond. Guess for now, the solution I posted is the best workaround.

 

[Anak]

I found a solution to the problem. If it gets stuck as it did in my case, click Debug -> Break -> then click on the command line box (next to kd>) -> Type "!analyze -v" (without quotes) -> Hit Enter

The WinDbg problem seems to occur when it cannot properly verify all driver dates. One of the times that I used the Break trick, it spit out about 20 drivers that were unable to have the dates verified. My guess is: the data for the dates gets corrupted and WinDbg can't verify them properly.

Instead of corruption it may be that the dates were never added to the driver package or they are in an area that the Dbg doesn't think to look.

Either case though, it would be highly unusual that, that would occur.