Jump to content

Random Blue Screen Error Message


adrian2055
 Share

Recommended Posts

I just re-installed vista a few days ago and now I get this error messgae:

*** STOP: 0x0000008E (0xc0000005, 0x92C6AD19, 0x95DE068C, 0x0000000)

*** win32k.sys - Address 92c6AD19 base at 92C50000, DateStamp 4bdc370f

It doesn't happen everytime I use my pc, but It's happened more than 10 times. What could be causing this?

Link to comment
Share on other sites


Do you have any .dmp files in your Windows directory or the minidump folder inside the windows directory? There can be many reasons, without seeing the dump that was (hopefully) generated from one of these it'll be hard to say.

Link to comment
Share on other sites

Do you have any .dmp files in your Windows directory or the minidump folder inside the windows directory? There can be many reasons, without seeing the dump that was (hopefully) generated from one of these it'll be hard to say.

I have one. It just happened again about 10 minutes ago while I was trying to browse my 2nd hard drive. The file is 195mb. Do I need to upload it?

Link to comment
Share on other sites

I just re-installed vista a few days ago and now I get this error messgae:

*** STOP: 0x0000008E (0xc0000005, 0x92C6AD19, 0x95DE068C, 0x0000000)

*** win32k.sys - Address 92c6AD19 base at 92C50000, DateStamp 4bdc370f

It doesn't happen everytime I use my pc, but It's happened more than 10 times. What could be causing this?

Hardware Fault, most probably bad memory module.

Run the memory diagnosis in vista or with a Linux Live CD, memtest86.

Link to comment
Share on other sites

Hardware Fault, most probably bad memory module

And you say this, based on what evidence? Not that running memtest86+ (yes, with a +) is a bad idea. It's even quite possible, but still. I don't see anything that surely means it's bad RAM based on what's been posted so far.

In this:

*** STOP: 0x0000008E (0xc0000005

There's already 2 interesting parts:

//

// MessageId: KERNEL_MODE_EXCEPTION_NOT_HANDLED

//

// MessageText:

//

// KERNEL_MODE_EXCEPTION_NOT_HANDLED

//

#define KERNEL_MODE_EXCEPTION_NOT_HANDLED ((ULONG)0x0000008EL)

(from bugcodes.h in the latest WinDDK)

//

// MessageId: STATUS_ACCESS_VIOLATION

//

// MessageText:

//

// The instruction at 0x%08lx referenced memory at 0x%08lx. The memory could not be %s.

//

#define STATUS_ACCESS_VIOLATION ((NTSTATUS)0xC0000005L) // winnt

(from ntstatus.h in the latest WinDDK)

This means there's a memory access violation. From what we know so far, it could be bad hardware, it could be a bad driver and several other things.

As for the dump, it's not a complete dump, and I can't really see anything interesting in the stack or anywhere else.

ChildEBP RetAddr

9aeaabc4 81a8fdd4 nt!MmAccessFault+0x10a

9aeaabc4 924fdea0 nt!KiTrap0E+0xdc

9aeaac4c 924fe0f3 win32k!CheckForMessageAccessCrossIL

9aeaac70 924fe0a8 win32k!CheckProcessIdentity+0x2d

9aeaac88 924a92ac win32k!xxxWrapRealDefWindowProc+0x16

9aeaace8 924fe074 win32k!NtUserfnINOUTLPWINDOWPOS+0x5f

9aeaad20 81a8cc7a win32k!NtUserMessageCall+0xc6

9aeaad20 774d5e74 nt!KiFastCallEntry+0x12a

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

0327f01c 00000000 0x774d5e74

(dds 9aeaad20 didn't give anything useful either)

Also:

1: kd> .bugcheck

Bugcheck code 00000050

Arguments eed737c5 00000000 924fdea0 00000002

where 924fdea0 is a memory address used by win32k.sys

92440000 92643000 win32k (pdb symbols)

so no help there either... Perhaps someone with a better windbg-fu (I'm definitely a n00b here) can get something from it though.

I'd set it up for a complete dump. And while I'd wait for a crash to happen, I'd have a good look at the event log for helpful clues (and have a peek for possible malware, shady drivers and what not, that the OS is fully patched, etc)

Link to comment
Share on other sites

1: kd> kn
*** Stack trace for last set context - .thread/.cxr resets it
# ChildEBP RetAddr
00 9aeaac4c 924fe0f3 win32k!CheckForMessageAccessCrossIL
01 9aeaac70 924fe0a8 win32k!CheckProcessIdentity+0x2d
02 9aeaac88 924a92ac win32k!xxxWrapRealDefWindowProc+0x16
03 9aeaace8 924fe074 win32k!NtUserfnINOUTLPWINDOWPOS+0x5f
04 9aeaad20 81a8cc7a win32k!NtUserMessageCall+0xc6
05 9aeaad20 774d5e74 nt!KiFastCallEntry+0x12a
WARNING: Frame IP not in any known module. Following frames may be wrong.
06 0327f01c 00000000 0x774d5e74

1: kd> dds 9aeaab50 9aeaabc4
9aeaab50 00000050
9aeaab54 eed737c5
9aeaab58 00000000
9aeaab5c 9aeaabdc
9aeaab60 00000002
9aeaab64 00000000
9aeaab68 eed737c5
9aeaab6c fe6048e8
9aeaab70 9aeaac70
9aeaab74 08214d55
9aeaab78 86168c98
9aeaab7c 00000000
9aeaab80 c0776b98
9aeaab84 eed737c5
9aeaab88 86168c80
9aeaab8c 00000000
9aeaab90 00000000
9aeaab94 00000000
9aeaab98 81a1670c hal!KfLowerIrql+0x64
9aeaab9c 00003bb0
9aeaaba0 9aeaabbc
9aeaaba4 9aeaabc0
9aeaaba8 92509e7e win32k!HANDLELOCK::vLockHandle+0x80
9aeaabac 00000000
9aeaabb0 00000000
9aeaabb4 ff800470
9aeaabb8 00000000
9aeaabbc 00000000
9aeaabc0 9aeaabf4
9aeaabc4 9aeaabdc

1: kd> r
eax=803d1120 ebx=00000000 ecx=81b42200 edx=000000ec esi=803d113c edi=00000000
eip=81ada38d esp=9aeaab50 ebp=9aeaabc4 iopl=0 nv up ei pl nz na pe nc
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00000206
nt!MmAccessFault+0x10a:
81ada38d 8b03 mov eax,dword ptr [ebx] ds:0023:00000000=????????

We don't really know anything about the user-mode portion of this stack, given your system is only configured for a kernel dump (and not a complete dump), but we do know the crash happened as a result of something that happened in explorer.exe, and we do know further that this occurred in a function used by win32k.sys to try and post a message to another thread, and on top of that we also know they are running in the same desktop (user session) by the usage of CheckForMessageAccessCrossIL (this function wouldn't be called if the message was to be posted to a thread in a process in another desktop session). However, there are PFNs missing from this dump that *should* have memory information available, so either there *is* a memory problem on this machine, or it was just that busy at the time of the dump that it is actually missing data. Obviously an attempt to MOV a 0x0 address into another valid address is going to give you an access violation, and because this is happening in kernel mode (nonpaged pool, to be exact) any page fault here is going to cause a bugcheck. In looking at the pool allocation referenced by the bugcheck:

1: kd> !pool eed737c5
Pool page eed737c5 region is Unknown
eed73000 is not a valid large pool allocation, checking large session pool...
eed73000 is freed (or corrupt) pool
Bad allocation size @eed73000, too large

1: kd> !poolval eed73000
Pool page eed73000 region is Unknown

Validating Pool headers for pool page: eed73000

Pool page [ eed73000 ] is __inVALID.

Analyzing linked list...


Scanning for single bit errors...

None found

It does appear this is an invalid memory address (it will show up as unallocated in this dump). It's a valid kernel-mode address, and where I'd expect nonpaged pool to contain, so the fact the nonpaged pool is invalid leaves us with three possible scenarios right now - one, it really was freed, and this is a double-free by a driver or kernel extension causing the bugcheck; two, the problem software is trying to read from a pool allocation that isn't really a valid pool address; or three, you do, in fact, have bad memory thus causing a valid PFN to point to a physical block of memory that is corrupt or invalid. All three are obviously bad, but only one can be fixed without an RMA of hardware ;).

At this point, I would suggest a memory test, but I'd also consider when this started happening, and at that point try to figure out if *anything* on the system was changed, updated, etc.

Link to comment
Share on other sites

I ran the internal vista memory test and it found no errors. As for changes made I added a 2nd hard drive (go here top see the hell I had with that: ), a dvd-rw drive and a new 1GB stick on memory (kingston). I switched the memory into different slots (I only have 2 slots, but belarc advisor shows me having 4). Bios originally said I only had 1.7 or 1.8gb of memory so I switched them to get bios to report it correctly. After I did that I did a bios update and a cmos reset as advised by a shuttle tech support agent since I discovered the original owner never updated the bios. When all of that was done I installed vista and everything was ok until this issue showed up.

BTW...I had one more blue screen early this morning, but this time the error was "ntfs.sys".

Link to comment
Share on other sites

This is interesting:

1: kd> .trap 0xffffffff8972997c
ErrCode = 00000000
eax=86644b00 ebx=00000000 ecx=807d18f2 edx=00010006 esi=866421e0 edi=89729cac
eip=81c5df62 esp=897299f0 ebp=89729ab8 iopl=0 nv up ei pl zr na pe nc
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00010246
nt!IopParseDevice+0xd38:
81c5df62 8b4b3c mov ecx,dword ptr [ebx+3Ch] ds:0023:0000003c=????????
1: kd> kb
*** Stack trace for last set context - .thread/.cxr resets it
ChildEBP RetAddr Args to Child
89729ab8 81c4c5e1 850cc0a0 00000000 864aab90 nt!IopParseDevice+0xd38
89729b48 81c59b62 00000000 89729ba0 00000040 nt!ObpLookupObjectName+0x5a8
89729ba8 81c3eed2 0014f788 00000000 81c5f401 nt!ObOpenObjectByName+0x13c
89729d54 81a69c7a 0014f788 0014f760 0014f7a8 nt!NtQueryAttributesFile+0x125
89729d54 773c5e74 0014f788 0014f760 0014f7a8 nt!KiFastCallEntry+0x12a
0014f740 773c4d60 76d4d2d3 0014f788 0014f760 ntdll!KiFastSystemCallRet
0014f744 76d4d2d3 0014f788 0014f760 0014f800 ntdll!NtQueryAttributesFile+0xc
0014f7a8 75c84dca 004fca10 00000000 0014f7e4 kernel32!GetFileAttributesW+0x5a
0014f7b8 75c85ae8 004fca10 004fb45c 20008000 SHELL32!kfapi::CFolderPathBuilder::Verify+0xf
0014f7e4 75c84e0e 004e92f8 20008000 004fca10 SHELL32!kfapi::CFolderPathBuilder::Create+0x92
0014f804 75c85890 0014f960 004e92f8 20008000 SHELL32!kfapi::CFolderPathBuilder::VerifyAndCreateFolder+0x24
0014f894 75c84f16 0014f960 00000000 20008000 SHELL32!kfapi::CFolderCache::GetPath+0x2ad
0014f8f8 75c84e78 0014f960 20008000 00000000 SHELL32!kfapi::CKFFacade::GetFolderPath+0x5d
0014f918 75c858fa 0014f960 20008000 00000000 SHELL32!SHGetKnownFolderPath_Internal+0x38
0014f934 75c7a0cd 0014f960 00000000 00000000 SHELL32!SHGetFolderPathEx+0x30
0014f974 0034dacb 00000000 0000801c 00000000 SHELL32!SHGetFolderPathW+0xac
0014fd4c 0034a91c 00340000 00000000 004d205e SearchIndexer!WinMain+0x1f3
0014fddc 76d4d0e9 7ffd9000 0014fe28 773a19bb SearchIndexer!__mainCRTStartup+0x140
0014fde8 773a19bb 7ffd9000 77561c5a 00000000 kernel32!BaseThreadInitThunk+0xe
0014fe28 773a198e 0034c9ad 7ffd9000 00000000 ntdll!__RtlUserThreadStart+0x23
0014fe40 00000000 0034c9ad 7ffd9000 00000000 ntdll!_RtlUserThreadStart+0x1b

1: kd> .printf "%mu", 0x96923a70
\Device\HarddiskVolume1\Windows\system32\config\systemprofile\AppData\Local

1: kd> dds 897299f0 89729ab8
897299f0 a4136dfe
897299f4 864aac34
897299f8 850cc088
897299fc 00000000
89729a00 00000002
89729a04 00000000
89729a08 8363805c
89729a0c 00000000
89729a10 864aab90
89729a14 00000080
89729a18 00200000
89729a1c 000000a8
89729a20 000000a8
89729a24 656c6946
89729a28 00000000
89729a2c 000007ff
89729a30 803da001
89729a34 86640418
89729a38 866540a8
89729a3c 00000000
89729a40 89729aa8
89729a44 00000000
89729a48 00000000
89729a4c 81c4d0ea nt!ObpFreeObject+0x192
89729a50 86654008
89729a54 00000000
89729a58 00000000
89729a5c 807d8bc4 fltmgr!FltpFastIoQueryOpen
89729a60 86654028
89729a64 864aab90
89729a68 00000000
89729a6c 86654008
89729a70 864aab90
89729a74 00000000
89729a78 00000080
89729a7c 00000000
89729a80 00000000
89729a84 8510ded8
89729a88 00000000
89729a8c 850cc0a0
89729a90 89729cac
89729a94 84d531a0
89729a98 00000000
89729a9c c500d120
89729aa0 897299f0
89729aa4 89729458
89729aa8 89729d44
89729aac 81a46ce9 nt!_except_handler4
89729ab0 acc67ed6
89729ab4 fffffffe
89729ab8 89729b48

Usually I don't see things like this unless a filter driver failed (it's a stack pointer error), but I don't see the call to IofCallDriver here - it could be that it failed before the box dumped, or the error caused it before we could walk the filter driver list to handle this. Assuming there are no permissions issues on this folder (this process looks like it requires write access to the system's %USERPROFILE% location), so you might want to disable indexing entirely and see if you get another crash. I'm still suspicious here about this though, it has an active IRP at the time of the failure - it might be relevant, it might just be white noise, but...

1: kd> lmivm cdrbsdrv
start end module name
8bbf7000 8bbfee00 cdrbsdrv (deferred)
Symbol file: cdrbsdrv.SYS
Image path: \SystemRoot\System32\Drivers\cdrbsdrv.SYS
Image name: cdrbsdrv.SYS
Timestamp: Tue Jun 16 23:37:15 2009 (4A3864EB)
CheckSum: 00013E19
ImageSize: 00007E00
File version: 8.1.1.0
Product version: 8.1.1.0
File flags: 8 (Mask 3F) Private
File OS: 40004 NT Win32
File type: 3.7 Driver
File date: 00000000.00000000
Translations: 0409.04b0
CompanyName: B.H.A Corporation
ProductName: B's Recorder GOLD
InternalName: CDRBSDRV.SYS
OriginalFilename: CDRBSDRV.SYS
ProductVersion: 8. 1. 1. 0
FileVersion: 8. 1. 1. 0
PrivateBuild: 8. 1. 1. 0
SpecialBuild: 8. 1. 1. 0
FileDescription: CD-ROM Filter Driver for Windows2000/xp
LegalCopyright: Copyright (C) 2000-2009 B.H.A Corporation
LegalTrademarks: Copyright (C) 2000-2009 B.H.A Corporation
Comments: Copyright (C) 2000-2009 B.H.A Corporation

It appears you were playing the file off of the CD drive, hence my suspicious nature of this - here's the devnode (\device\disk) showing the hard disk, the ecache (decompression) IRP from WMP that comes from it, and the IRP it's waiting on (atapi.sys):

1: kd> !DevNode 843fa8b8 
DevNode 0x843fa8b8 for PDO 0x84400030
Parent 0x83a82ad0 Sibling 0000000000 Child 0000000000
InstancePath is "IDE\DiskWDC_WD10EADS-11M2B1_____________________80.00A80\5&228e3881&0&1.0.0"
ServiceName is "disk"
State = DeviceNodeStarted (0x308)
Previous State = DeviceNodeEnumerateCompletion (0x30d)
StateHistory[08] = DeviceNodeEnumerateCompletion (0x30d)
StateHistory[07] = DeviceNodeEnumeratePending (0x30c)
StateHistory[06] = DeviceNodeStarted (0x308)
StateHistory[05] = DeviceNodeStartPostWork (0x307)
StateHistory[04] = DeviceNodeStartCompletion (0x306)
StateHistory[03] = DeviceNodeResourcesAssigned (0x304)
StateHistory[02] = DeviceNodeDriversAdded (0x303)
StateHistory[01] = DeviceNodeInitialized (0x302)
StateHistory[00] = DeviceNodeUninitialized (0x301)
StateHistory[19] = Unknown State (0x0)
StateHistory[18] = Unknown State (0x0)
StateHistory[17] = Unknown State (0x0)
StateHistory[16] = Unknown State (0x0)
StateHistory[15] = Unknown State (0x0)
StateHistory[14] = Unknown State (0x0)
StateHistory[13] = Unknown State (0x0)
StateHistory[12] = Unknown State (0x0)
StateHistory[11] = Unknown State (0x0)
StateHistory[10] = Unknown State (0x0)
StateHistory[09] = Unknown State (0x0)
Flags (0x00000130) DNF_ENUMERATED, DNF_IDS_QUERIED,
DNF_NO_RESOURCE_REQUIRED

1: kd> !irp 86633438
Irp is active with 8 stacks 4 is current (= 0x86633514)
Mdl=85779f18: No System Buffer: Thread 862a2850: Irp stack trace.
cmd flg cl Device File Completion-Context
[ 0, 0] 0 0 00000000 00000000 00000000-00000000

Args: 00000000 00000000 00000000 00000000
[ 0, 0] 0 0 00000000 00000000 00000000-00000000

Args: 00000000 00000000 00000000 00000000
[ 0, 0] 0 0 00000000 00000000 00000000-00000000

Args: 00000000 00000000 00000000 00000000
>[ 3,34] 10 e0 84c50608 00000000 8070f134-00000000 Success Error Cancel
\Driver\disk partmgr!PmReadWriteCompletion
Args: 00001000 00000000 dbb10000 00000008
[ 3, 0] 10 e0 84c50230 00000000 8071e4d4-84e563c0 Success Error Cancel
\Driver\partmgr volmgr!VmpReadWriteCompletionRoutine
Args: 090b6192 00000000 dbb10000 00000008
[ 3, 0] 0 e0 84e56308 00000000 8799e9ac-850d0c20 Success Error Cancel
\Driver\volmgr fvevol!PassThroughCompletion
Args: 090b6189 00000000 dba10000 00000008
[ 3, 0] 0 e0 850d0b68 00000000 87976cc6-86640118 Success Error Cancel
\Driver\fvevol ecache!EcDispatchReadWriteCompletion
Args: 00001000 00000000 dba10000 00000008
[ 3, 0] 0 0 850d1690 00000000 00000000-00000000
\Driver\Ecache
Args: 00001000 00000000 dba10000 00000008

1: kd> !irp 845118d0
Irp is active with 3 stacks 3 is current (= 0x84511988)
Mdl=85779f18: No System Buffer: Thread 00000000: Irp stack trace.
cmd flg cl Device File Completion-Context
[ 0, 0] 0 0 00000000 00000000 00000000-00000000

Args: 00000000 00000000 00000000 00000000
[ 0, 0] 0 0 00000000 00000000 00000000-00000000

Args: 00000000 00000000 00000000 00000000
>[ f, 0] 10 e1 84400030 00000000 879cf138-850cc538 Success Error Cancel pending
\Driver\atapi CLASSPNP!TransferPktComplete
Args: 850cc5e4 00000000 00000000 84e56600

Edited by cluberti
Updated
Link to comment
Share on other sites

What are you suspicious of? I'm curious as to what you're thinking because I've never seen anything like this. I had 2 more since this one. This time all I did was turn on my pc and I got the blue screen a few seconds after I go to my desktop. I'll try turning off indexing like you said.

Link to comment
Share on other sites

What are you suspicious of? I'm curious as to what you're thinking because I've never seen anything like this. I had 2 more since this one. This time all I did was turn on my pc and I got the blue screen a few seconds after I go to my desktop. I'll try turning off indexing like you said.

I'd like to see one or two more of these - if they're all random, then the above could just be because of bad RAM, unfortunately. I'd like to see more to make sure my analysis above isn't just a victim of some other cause. If they're all 50 and 8E bugchecks, however, this could actually be a filesystem or filter driver issue.

Link to comment
Share on other sites

What are you suspicious of? I'm curious as to what you're thinking because I've never seen anything like this. I had 2 more since this one. This time all I did was turn on my pc and I got the blue screen a few seconds after I go to my desktop. I'll try turning off indexing like you said.

I'd like to see one or two more of these - if they're all random, then the above could just be because of bad RAM, unfortunately. I'd like to see more to make sure my analysis above isn't just a victim of some other cause. If they're all 50 and 8E bugchecks, however, this could actually be a filesystem or filter driver issue.

I'm uploading the other one so you can look at it. I really hope it's not the ram.

Edited by adrian2055
Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
 Share

  • Recently Browsing   0 members

    • No registered users viewing this page.


×
×
  • Create New...