Thanks Brian, that's what I meant to say :-) I'd done this once before to troubleshoot a misbehaving driver, but forgot the correct term. Spent some time this afternoon re-reading Mark Russinovich's blog to refresh my memory on how Windows manages and realized that was probably the only way to determine the cause.
Jeff On Wed, Jun 15, 2011 at 4:38 PM, Brian Desmond <[email protected]>wrote: > *Pool tagging won’t help (it’s actually enabled by default in 2003+), but, > you’d probably want to have special pool enabled. You can enable it on a per > driver basis, I’d do all 3rd party drivers. There is certainly a perf hit > involved to some extent. If you’re not going to do this, your chances of > diagnosing this are going to be really slim. * > > * * > > *Thanks,* > > *Brian Desmond* > > *[email protected]* > > * * > > *w – 312.625.1438 | c – 312.731.3132* > > * * > > *From:* Jeff Bunting [mailto:[email protected]] > *Sent:* Wednesday, June 15, 2011 2:13 PM > *To:* NT System Admin Issues > *Subject:* crash dump debugging > > > > Have a VM (ESX3.5) that has begun to BSOD with a > PAGE_FAULT_IN_NONPAGED_AREA that I'm trying to figure out. Every crash has > been win32k.sys referencing memory that doesn't appear to be allocated to a > process. > > > > 3 out of 4 crashes has been the same address, bda40b20 though the calling > process had differed; net1.exe, cmd.exe, bash.exe (cygwin). The application > runs a lot of scripts; I'm assuming that the crash is occurring while > launching or running one of these. Is there anything more information that > I can gather from these dumps? > > > > This is a heavily used production system, so I can't enable pool tagging or > anything that will tax the system. OS is Win2003 SP2 Ent and is running > McAfee 8.5i. McAfee On-Access Scanner is enabled, but not other features > (access protection, buffer overflow protection). The first BSOD happened a > month ago and have had 3 in the past two days. Nothing has changed on the > OS I'm aware of. > > > > > > PAGE_FAULT_IN_NONPAGED_AREA (50) > > Invalid system memory was referenced. This cannot be protected by > try-except, > > it must be protected by a Probe. Typically the address is just plain bad > or it > > is pointing at freed memory. > > Arguments: > > Arg1: bda40b20, memory referenced. > > Arg2: 00000000, value 0 = read operation, 1 = write operation. > > Arg3: bf8b7fdf, If non-zero, the instruction address which referenced the > bad memory > > address. > > Arg4: 00000000, (reserved) > > > > Debugging Details: > > ------------------ > > > > > > Could not read faulting driver name > > > > READ_ADDRESS: bda40b20 > > > > FAULTING_IP: > > win32k!DestroyThreadsObjects+4f > > bf8b7fdf 8b01 mov eax,dword ptr [ecx] > > > > MM_INTERNAL_CODE: 0 > > > > CUSTOMER_CRASH_COUNT: 1 > > > > DEFAULT_BUCKET_ID: DRIVER_FAULT_SERVER_MINIDUMP > > > > BUGCHECK_STR: 0x50 > > > > PROCESS_NAME: net1.exe > > > > CURRENT_IRQL: 1 > > > > TRAP_FRAME: 90f7fb98 -- (.trap 0xffffffff90f7fb98) > > ErrCode = 00000000 > > eax=bda40af0 ebx=00000187 ecx=bda40b20 edx=80000002 esi=e1158a70 > edi=00001254 > > eip=bf8b7fdf esp=90f7fc0c ebp=90f7fc58 iopl=0 nv up ei pl zr na pe > nc > > cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 > efl=00010246 > > win32k!DestroyThreadsObjects+0x4f: > > bf8b7fdf 8b01 mov eax,dword ptr [ecx] > ds:0023:bda40b20=???????? > > Resetting default scope > > > > LAST_CONTROL_TRANSFER: from 8085ed47 to 80827c83 > > > > STACK_TEXT: > > 90f7fb08 8085ed47 00000050 bda40b20 00000000 nt!KeBugCheckEx+0x1b > > 90f7fb80 8088c820 00000000 bda40b20 00000000 nt!MmAccessFault+0xb25 > > 90f7fb80 bf8b7fdf 00000000 bda40b20 00000000 nt!KiTrap0E+0xdc > > 90f7fc14 bf8b832c 8d35c500 00000000 00000000 > win32k!DestroyThreadsObjects+0x4f > > 90f7fc58 bf8b6bd1 00000001 90f7fc80 bf8b7a2e > win32k!xxxDestroyThreadInfo+0x206 > > 90f7fc64 bf8b7a2e 8d35c500 00000001 00000000 win32k!UserThreadCallout+0x4b > > 90f7fc80 8094c3d2 8d35c500 00000001 8d35c500 win32k!W32pThreadCallout+0x3a > > 90f7fd0c 8094c765 00000000 00000000 8d954458 nt!PspExitThread+0x3b2 > > 90f7fd24 8094c95f 8d35c500 00000000 00000001 > nt!PspTerminateThreadByPointer+0x4b > > 90f7fd54 808897ec 00000000 00000000 0007fe3c nt!NtTerminateProcess+0x125 > > 90f7fd54 7c82847c 00000000 00000000 0007fe3c nt!KiFastCallEntry+0xfc > > WARNING: Frame IP not in any known module. Following frames may be wrong. > > 0007fe3c 00000000 00000000 00000000 00000000 0x7c82847c > > > > > > STACK_COMMAND: kb > > > > FOLLOWUP_IP: > > win32k!DestroyThreadsObjects+4f > > bf8b7fdf 8b01 mov eax,dword ptr [ecx] > > > > SYMBOL_STACK_INDEX: 3 > > > > SYMBOL_NAME: win32k!DestroyThreadsObjects+4f > > > > FOLLOWUP_NAME: MachineOwner > > > > MODULE_NAME: win32k > > > > IMAGE_NAME: win32k.sys > > > > DEBUG_FLR_IMAGE_TIMESTAMP: 4d6f9db6 > > > > FAILURE_BUCKET_ID: 0x50_win32k!DestroyThreadsObjects+4f > > > > BUCKET_ID: 0x50_win32k!DestroyThreadsObjects+4f > > > > > > Thanks, > > Jeff > > ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ > ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~ > > --- > To manage subscriptions click here: > http://lyris.sunbelt-software.com/read/my_forums/ > or send an email to [email protected] > with the body: unsubscribe ntsysadmin > > ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ > ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~ > > --- > To manage subscriptions click here: > http://lyris.sunbelt-software.com/read/my_forums/ > or send an email to [email protected] > with the body: unsubscribe ntsysadmin > ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~ --- To manage subscriptions click here: http://lyris.sunbelt-software.com/read/my_forums/ or send an email to [email protected] with the body: unsubscribe ntsysadmin
