System Recovered From a Serious Error

Maybe :-),

I like BSV just fine, but when I suggest it, I include a disclaimer:

BlueScreenView tries to locate the right driver or module that caused the blue screen by looking inside the crash stack. However, be aware that the driver detection mechanism is not 100% accurate, and you should also look in the lower pane, that display all drivers/modules found in the stack.

Sometimes BlueScreenView will implicate XP files as the cause of the crash (ntoskrnl.exe, win32k.sys, hal.dll, etc.) but they are probably not the real cause of the crash (BSV does the best it can) and you need to look at some other crash dumps or use the Windows debugging tools to dig a little deeper into the crash dump to find the real cause.

Even WhoCrashed says:

Possibly this problem is caused by another driver that cannot be identified at this time.

Using the Windows debugging tools, it says:

Debugging Details:

BUGCHECK_STR:  0x1a_4128b

CUSTOMER_CRASH_COUNT:  1

DEFAULT_BUCKET_ID:  DRIVER_FAULT

PROCESS_NAME:  wmpnetwk.exe

LAST_CONTROL_TRANSFER:  from 80525171 to 805338be

STACK_TEXT: 

b9d54b9c 80525171 0000001a 0004128b 006d1201 nt!KeBugCheckEx+0x1b

b9d54bd0 804e71b8 0000062e 00001b18 006d1201 nt!MiSwapWslEntries+0x157

b9d54bfc 804e9138 b9d54c28 c050a2fc 89a4ea28 nt!MiUpdateWsle+0x159

b9d54c20 804e99ac 00001b18 c01f2200 81d9a190 nt!MiAddValidPageToWorkingSet+0x99

b9d54c50 804e98b4 00000000 7c880b0f c01f2200 nt!MiCompleteProtoPteFault+0x167

b9d54c80 804e92b7 00000000 7c880b0f c01f2200 nt!MiResolveProtoPteFault+0x17d

b9d54cfc 804e9036 00000000 7c880b0f c01f2200 nt!MiDispatchFault+0x13b

b9d54d4c 804e172b 00000000 7c880b0f 01000001 nt!MmAccessFault+0xc09

b9d54d4c 7c880b0f 00000000 7c880b0f 01000001 nt!KiTrap0E+0xcc

WARNING: Frame IP not in any known module. Following frames may be wrong.

00c4fb20 00000000 00000000 00000000 00000000 0x7c880b0f

STACK_COMMAND:  kb

FOLLOWUP_IP:

nt!MiSwapWslEntries+157

80525171 8b4d10          mov     ecx,dword ptr [ebp+10h]

SYMBOL_STACK_INDEX:  1

SYMBOL_NAME:  nt!MiSwapWslEntries+157

FOLLOWUP_NAME:  MachineOwner

MODULE_NAME: nt

DEBUG_FLR_IMAGE_TIMESTAMP:  50338d20

IMAGE_NAME:  memory_corruption

FAILURE_BUCKET_ID:  0x1a_4128b_nt!MiSwapWslEntries+157

BUCKET_ID:  0x1a_4128b_nt!MiSwapWslEntries+157

Followup: MachineOwner

I will use BSV first usually, then if it implicates an XP file like hal.dll, ntoskrnl.exe, win32k.sys or whatever else it says about XP files, I just don't believe it and I will use the Windows debugger.

Even if BSV says it is some other file that you recognize as third party, I still use the debugger since I can get more information about the crash and other system information (like system make and model, etc.) and if there is a third party file, you can also usually get the version of the file and other things.

If we get more crash dumps, and they keep pointing to the same thing, we can look more closely at that.

I have BSV in my minidump folder and made a little batch file that runs the Windows debugger in there too, so I just copy the crash dumps to look at in my minidump folder, run BSV and see what it has to say, then run the batch file that launches the debugger (I am so lazy) and see what I can see in that.

Finally, let me elaborate a little on the loss of data after running check disk. The data is not actually lost per se. The files are all placed into a folder with each having a chk file extension. There are software now which detects the original format then converts it back. A lot of trouble for a circumstance which can be easily avoided. 

 Interesting! I didn't know that.

IIRC (and I might not be!), I recall a series of issues, including conflicting AV programs AND OP's graphics driver.

The OP did have an issue with his graphics driver. However, it was not the cause of a BSOD. Since this issue is about BSODs I made the comment I did above. Regardless, the OP's primary issue in his previous thread was malware.

Finally, let me elaborate a little on the loss of data after running check disk. The data is not actually lost per se. The files are all placed into a folder with each having a chk file extension. There are software now which detects the original format then converts it back. A lot of trouble for a circumstance which can be easily avoided.

IIRC (and I might not be!), I recall a series of issues, including conflicting AV programs AND OP's graphics driver.

Excellent advice to back up data first, by the way.

So you didn't see anything unusual in the logs, or something we could work on? I know my machine is getting old ..

What I am saying is this. There is no need whatsoever to go on a fishing expedition for an issue that may not exist. BSODs can and do sometimes happen even when nothing is really wrong with the computer in question. BSODs should, for the most part, be ignored UNLESS they become frequent.

Also, while the dump file states the error was a result of Memory Management, most often this error is not the ram. It is most often a fluke between the installed ram and pagefile. That is not always the case though.

This issue, the BSOD, is in no way related to the BSODs you were getting in your previous thread. Those were caused by conflicting security software drivers.

Finally, if you are dead set on trying to locate and resolve the issue then by all means do so. However, it is my opinion it would be a waste of time unless the errors began to occur more often. Moreover, you can end up causing more issues than you originally had. As stated, a perfectly good running computer can crash with a BSOD out of nowhere and never happen a second or subsequent time.

If it were my computer, I would be backing up all my personal data then run check disk as suggested by Dave. While not always the case, an autocheck is often a good indication of a failing hard drive. We do often, and erroneously, give instructions to run check disk and we do not warn against not backing up personal data. I, for one, am attempting to break that habit as running check disk can and often does result in lost personal data.