Windbg unable to load unloaded module list

[Mario F.]

When trying to debug crashdump, I'm having windbg stop while trying to load unloaded modules. I checked the modules list and this is what comes up as part of the unloaded modules:

<Unloaded>    a348a000    a34f4000    Thu Jan 01 00:00:00 1970 (00000000)    00000000    None    spsys.sys
<Unloaded>    a406b000    a4083000    Thu Jan 01 00:00:00 1970 (00000000)    00000000    None    parport.sys
<Unloaded>    8d627000    8d634000    Thu Jan 01 00:00:00 1970 (00000000)    00000000    None    crashdmp.sys
<Unloaded>    8d634000    8d63f000    Thu Jan 01 00:00:00 1970 (00000000)    00000000    None    dump_ataport
<Unloaded>    8d63f000    8d648000    Thu Jan 01 00:00:00 1970 (00000000)    00000000    None    dump_atapi.s
<Unloaded>    8d648000    8d659000    Thu Jan 01 00:00:00 1970 (00000000)    00000000    None    dump_dumpfve

No checksum and a 0 timestamp. Have I the wrong symbols? Not that there's much to choose from under Windows 7 symbol package lists. I've downloaded and installed to c:\symbols the first entry under symbols for Windows 7 and Windows Server 2008 R2. My symbol path is set as:

srv*c:\symbols*http://msdl.microsoft.com/download/symbols

Why I try to reload one of them, I get the following:

0: kd> .reload /f @"spsys.sys"

"spsys.sys" was not found in the image list.
Debugger will attempt to load "spsys.sys" at given base 00000000.

Please provide the full image name, including the extension (i.e. kernel32.dll)
for more reliable results.Base address and size overrides can be given as
.reload <image.ext>=<base>,<size>.
SYMSRV:  c:\symbols\spsys.sys\FFFFFFFE\spsys.sys not found
SYMSRV:  http://msdl.microsoft.com/download/symbols/spsys.sys/FFFFFFFE/spsys.sys not found
DBGHELP: C:\Program Files\Debugging Tools for Windows (x86)\spsys.sys - file not found
SYMSRV:  c:\symbols\spsys.sys\FFFFFFFE\spsys.sys not found
SYMSRV:  http://msdl.microsoft.com/download/symbols/spsys.sys/FFFFFFFE/spsys.sys not found
DBGENG:  spsys.sys - Image mapping disallowed by non-local path.
Unable to load image spsys.sys, Win32 error 0n2
DBGENG:  spsys.sys - Partial symbol image load missing image info
DBGHELP: No header for spsys.sys.  Searching for dbg file
DBGHELP: .\spsys.dbg - file not found
DBGHELP: .\sys\spsys.dbg - path not found
DBGHELP: .\symbols\sys\spsys.dbg - path not found
DBGHELP: spsys.sys missing debug info.  Searching for pdb anyway
DBGHELP: Can't use symbol server for spsys.pdb - no header information available
DBGHELP: spsys.pdb - file not found
DBGHELP: spsys - no symbols loaded
Unable to add module at 00000000

[Codeplug]

>> Have I the wrong symbols?
I've never used a symbol package - instead I just use the MS symbol server, same as you have configured.

>> ... this is what comes up as part of the unloaded modules:
I wouldn't worry about the unloaded modules - unless of course that is where the crash is being reported.

Being Win7, you may want to run Windbg as administrator.

It's good to check for a new version of Windbg every once in a while too (it's at 6.12.2.633 as of this post).

gg

[Mario F.]

Yes. I have the latest one. Problem really is that the debugger stops while trying to load these unloaded modules and doesn't seem to do the minidump analysis. If I set it to automatically open the disassembly, the disassembly window does open and places me under the bugcheck. But there's no analysis in the command window.

[Mario F.]

Nevermind I'm an idiot. It's all well. I was just used to see a header before doing "!analyze -v". That header for some reason isn't there anymore, but I can do the analysis nonetheless.

[Codeplug]

>> It's all well.
At least you didn't post #4.

gg

[brewbuck]

You can't get symbols for spsys.sys because it is part of the Windows licensing mechanism. Microsoft chooses not to make symbols available externally for this module for some reasons that should hopefully be obvious.

However, that wasn't really your problem (which you seem to have solved on your own)

[Mario F.]

I've been doing the analysis of the minidumps for those BSODs I experienced before. And all 5 of them, including an isolated one I got yesterday while running the computer under default BIOS settings, happen with memory transfer actions. The last one is in fact clearly indicated as memory_corruption in the image name.

I've ran memtest86+ all night and it consistently reports errors on test 5, and only on test 5. Weird. The summary report lists them as ECC Recoverable Errors. But there are two many for comfort. 606 in 11 passes.

Being unlucky with this machine for sure. Seems I've been having bad ram all along.

>> At least you didn't post #4.

At least I didn't run it...

[cyberfish]

That's pretty clearly bad memory. If they are running at stock settings, they are defective and you should return them.

When it comes to memory 1 error is 1 too many, and they usually worsen as the memory goes through thermal cycles.

There's also a chance it's the memory controller or something else (power supply, etc), but 95% of the time it's the sticks.

[Mario F.]

>> There's also a chance it's the memory controller or something else (power supply, etc), but 95% of the time it's the sticks.

Yeah, that occurred to me. Especially when I read memtest documentation. So after testing both DIMMS on their normal positions, I tested them individually (I also wanted to find out if it was both DIMMs, or just one).

It's indeed one of the DIMMs. The other is fine after 5 passes (about 1 hour testing). I suppose if both had failed it could still mean another hardware problem. But with both being tested individually on the same slot and one of them passing while the other not, I think pretty much covers that up.