Ken Schaefer

I am running sbs 2003 sp 1. I have been having repeat crashes. I enabled the driver verifier and now Windows crashes while loading. Please advise, what do I do now?

Hi Nat,

You need to get the minidump files from c:\windows\minidump and analyze them using WinDBG per Part 2 of this series.

You can boot your machine into Safe Mode (hopefully the faulty driver is not being loaded in Safe Mode) or use something like WinPE to boot the machine and get access to the disk.

Alternatively, if this is a business system, then please call Microsoft PSS and open a support call. Since this is a business-down situation, it will be attended to promptly.

Hi, i did what you said in part 2 but dont know what to do next? This is my info: READ_ADDRESS: 00000016 CURRENT_IRQL: 1c FAULTING_IP: nt!KiWaitTest+30 80502392 6683781601 cmp word ptr [eax+16h],1 CUSTOMER_CRASH_COUNT: 1 DEFAULT_BUCKET_ID: DRIVER_FAULT BUGCHECK_STR: 0xA PROCESS_NAME: bsplayer.exe LAST_CONTROL_TRANSFER: from 804fa146 to 80502392 STACK_TEXT: b5db6850 804fa146 b5db6c84 b5db6ce8 e115b018 nt!KiWaitTest+0x30 b5db6864 bfa14370 8876c888 00000000 00000000 nt!KeSetEvent+0x5a WARNING: Stack unwind information not available. Following frames may be wrong. b5db6888 bf9d782b 00000000 e16b8714 b5db6ce8 atkosdmini+0x1370 b5db6c98 bf908170 b5db6ce8 e16b8714 e3d2a780 atkdisp+0x282b b5db6cd0 bf9c8329 b5db6ce8 b5db6d64 0469fb9c win32k!WatchdogDdFlip+0x38 b5db6d48 8054086c 02400003 02400005 00000000 dxg!DxDdFlip+0x261 b5db6d48 7c90eb94 02400003 02400005 00000000 nt!KiFastCallEntry+0xfc 0469fba4 00000000 00000000 00000000 00000000 0x7c90eb94 STACK_COMMAND: kb FOLLOWUP_IP: atkosdmini+1370 bfa14370 ?? ??? SYMBOL_STACK_INDEX: 2 SYMBOL_NAME: atkosdmini+1370 FOLLOWUP_NAME: MachineOwner MODULE_NAME: atkosdmini IMAGE_NAME: atkosdmini.dll DEBUG_FLR_IMAGE_TIMESTAMP: 45bd5dcc FAILURE_BUCKET_ID: 0xA_atkosdmini+1370 BUCKET_ID: 0xA_atkosdmini+1370 Followup: MachineOwner --------- 0: kd> lmvm atkosdmini start end module name bfa13000 bfa15c00 atkosdmini T (no symbols) Loaded symbol image file: atkosdmini.dll Image path: atkosdmini.dll Image name: atkosdmini.dll Timestamp: Mon Jan 29 03:37:00 2007 (45BD5DCC) CheckSum: 00002CE8 ImageSize: 00002C00 Translations: 0000.04b0 0000.04e0 0409.04b0 0409.04e0

Hi

Bug in either atkosdmini.dll or atkdisp.sys. I believe that these are ASUS drivers for some kind of hardware in your machine (probably video card).

See if you can get updated versions of these files from ASUS (or open a support case with them).

Cheers

Ken

Any idea what this could be? Memory tests ok. ******************************************************************************* * * * Bugcheck Analysis * * * ******************************************************************************* Use !analyze -v to get detailed debugging information. BugCheck 1000000A, {a10002a, 2, 0, 804da6db} Probably caused by : ntoskrnl.exe ( nt!KeSynchronizeExecution+5 ) Followup: MachineOwner --------- kd> !analyze -v ******************************************************************************* * * * Bugcheck Analysis * * * ******************************************************************************* IRQL_NOT_LESS_OR_EQUAL (a) An attempt was made to access a pageable (or completely invalid) address at an interrupt request level (IRQL) that is too high. This is usually caused by drivers using improper addresses. If a kernel debugger is available get the stack backtrace. Arguments: Arg1: 0a10002a, memory referenced Arg2: 00000002, IRQL Arg3: 00000000, bitfield : bit 0 : value 0 = read operation, 1 = write operation bit 3 : value 0 = not an execute operation, 1 = execute operation (only on chips which support this level of status) Arg4: 804da6db, address which referenced memory Debugging Details: ------------------ READ_ADDRESS: 0a10002a CURRENT_IRQL: 2 FAULTING_IP: nt!KeSynchronizeExecution+5 804da6db 8b4b29 mov ecx,dword ptr [ebx+29h] CUSTOMER_CRASH_COUNT: 1 DEFAULT_BUCKET_ID: DRIVER_FAULT BUGCHECK_STR: 0xA PROCESS_NAME: System LAST_CONTROL_TRANSFER: from 804dbbd4 to 804da6db STACK_TEXT: f7c26fd0 804dbbd4 861a49e8 861a49d4 00000000 nt!KeSynchronizeExecution+0x5 f7c26ff4 804db89e f7c3aad0 00000000 00000000 nt!KiRetireDpcList+0x46 f7c26ff8 f7c3aad0 00000000 00000000 00000000 nt!KiDispatchInterrupt+0x2a WARNING: Frame IP not in any known module. Following frames may be wrong. 804db89e 00000000 00000009 bb835675 00000128 0xf7c3aad0 STACK_COMMAND: kb FOLLOWUP_IP: nt!KeSynchronizeExecution+5 804da6db 8b4b29 mov ecx,dword ptr [ebx+29h] SYMBOL_STACK_INDEX: 0 SYMBOL_NAME: nt!KeSynchronizeExecution+5 FOLLOWUP_NAME: MachineOwner MODULE_NAME: nt IMAGE_NAME: ntoskrnl.exe DEBUG_FLR_IMAGE_TIMESTAMP: 45e54711 FAILURE_BUCKET_ID: 0xA_nt!KeSynchronizeExecution+5 BUCKET_ID: 0xA_nt!KeSynchronizeExecution+5 Followup: MachineOwner

Hi Tyler,

Did you enable verifier.exe prior to obtaining this dump file?

Cheers

Ken

******************************************************************************* * * * Bugcheck Analysis * * * ******************************************************************************* IRQL_NOT_LESS_OR_EQUAL (a) An attempt was made to access a pageable (or completely invalid) address at an interrupt request level (IRQL) that is too high. This is usually caused by drivers using improper addresses. If a kernel debugger is available get the stack backtrace. Arguments: Arg1: 00000029, memory referenced Arg2: 00000002, IRQL Arg3: 00000000, bitfield : bit 0 : value 0 = read operation, 1 = write operation bit 3 : value 0 = not an execute operation, 1 = execute operation (only on chips which support this level of status) Arg4: 804da6db, address which referenced memory Debugging Details: ------------------ READ_ADDRESS: 00000029 CURRENT_IRQL: 2 FAULTING_IP: nt!KeSynchronizeExecution+5 804da6db 8b4b29 mov ecx,dword ptr [ebx+29h] CUSTOMER_CRASH_COUNT: 10 DEFAULT_BUCKET_ID: COMMON_SYSTEM_FAULT BUGCHECK_STR: 0xA TRAP_FRAME: 80550318 -- (.trap 0xffffffff80550318) ErrCode = 00000000 eax=85004448 ebx=00000000 ecx=fffffffe edx=00000000 esi=85004410 edi=f72f4d90 eip=804da6db esp=8055038c ebp=805503ac iopl=0 nv up ei ng nz na pe nc cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00010286 nt!KeSynchronizeExecution+0x5: 804da6db 8b4b29 mov ecx,dword ptr [ebx+29h] ds:0023:00000029=???????? Resetting default scope LAST_CONTROL_TRANSFER: from 804da6db to 804e187f STACK_TEXT: 80550318 804da6db badb0d00 00000000 85c10ffc nt!KiTrap0E+0x233 805503ac 804dbbd4 85c0a418 85c0a404 00000000 nt!KeSynchronizeExecution+0x5 805503d0 804dbb4d 00000000 0000000e 00000000 nt!KiRetireDpcList+0x46 805503d4 00000000 0000000e 00000000 00000000 nt!KiIdleLoop+0x26 STACK_COMMAND: kb FOLLOWUP_IP: nt!KeSynchronizeExecution+5 804da6db 8b4b29 mov ecx,dword ptr [ebx+29h] SYMBOL_STACK_INDEX: 1 SYMBOL_NAME: nt!KeSynchronizeExecution+5 FOLLOWUP_NAME: MachineOwner MODULE_NAME: nt IMAGE_NAME: ntoskrnl.exe DEBUG_FLR_IMAGE_TIMESTAMP: 45e54711 FAILURE_BUCKET_ID: 0xA_nt!KeSynchronizeExecution+5 BUCKET_ID: 0xA_nt!KeSynchronizeExecution+5 Followup: MachineOwner -----

Hi Ken and others, as above, I gotta exactly the same problem as Tyler's. I tried verifier.exe,but it didn't help.

Hi Jason,

Verifier.exe doesn't stop you getting BSODs. What it does is stop a driver corrupting memory, and then causing something else to crash. Instead the culprit will be caught in the act. Your machine will still BSOD, but at least the culprit will be on the stack.

Hi Ken, thank u for your timely response. But when I set the verifer manager to verify all the drivers installed, it cannot load even before the windows starts. Just as the 1st post here. Then I did what u suggest, start in safe mode,and check with dmp file again. Exactly the same information. It seems I have no way to figure out the true culprit!

FYI, I spent the whole nite to search related information. It seems some guys said with "IMAGE_NAME: ntoskrnl.exe" in the dmp file. It is very likely something wrong with the hardware, say bad RAM, bad hd or motherboard. I am now running memtest 2.01, and it seems no problem with my RAM now. Another possiblity is virtual memory,e.g. I set some size of hard disk to be the virtual memory, could it be that because something wrong with part of hard disk(say,bad sector), and when the windows uses virtual memory and encounters that part of bad sector of hard disk, and gotta crashed?

Great series. Thanks for putting it together...

Hi Jason,

You can check for disk errors using chkdsk.exe. Alternatively you can boot from your Windows CD to the Recovery Console (XP) or Recovery Tools (Vista) and run autochk (or equivelent Vista tool - I don't know what that is) to check the disk.

If some of your Windows binaries are corrupt then they can be repaired using a Repair Install.

You might want to contact Microsoft PSS (Product Support Services) for additional help if you don't think it's a hardware issue. Advice them that you are getting a BSOD early in the boot process after enabling Driver Verifier (so that you don't have to waste time dealing with low level support).

Nice series.  Thanks for doing it.  I have a server with several telecom cards (dialogic) in it.  It runs MS Forefront for anti virus.  I use Tivoli 5.5 for archive backup.  About once per week in the early morning I get a BSOD.  I ran the debug tools and here is the output:

1: kd> .symfix

No downstream store given, using C:\Program Files\Debugging Tools for Windows (x86)\sym

1: kd> .reload

Loading Kernel Symbols

...............................................................................................................

Loading User Symbols

PEB is paged out (Peb.Ldr = 7ffdd00c).  Type ".hh dbgerr001" for details

Loading unloaded module list

.........

1: kd> kb

ChildEBP RetAddr  Args to Child              

f76267f0 80801481 badb0d00 81400000 e7665c78 nt!KiTrap0E+0x2a7

f7626874 808885a1 89d6b048 ffffffff 86e3dd38 nt!MiRestoreTransitionPte+0xa0

f762688c 8086b6c5 f043b3a8 808277dc 000fffff nt!MiRemovePageFromList+0xd1

f7626894 808277dc 000fffff c53fd4dc c8780000 nt!MiRemoveAnyPage+0x68

f76268cc 808264f4 f7727120 00001000 00000000 nt!MiResolveMappedFileFault+0x5cd

f7626900 80847d0e 00000000 c8780000 c0321e00 nt!MiResolveProtoPteFault+0x1a6

f7626998 8084790e 00000001 c8780000 c0321e00 nt!MiDispatchFault+0x87e

f76269f4 8082671d 00000000 c8780000 00000000 nt!MmAccessFault+0x64a

f7626a24 809375a6 c8780000 00000000 87374020 nt!MmCheckCachedPageState+0x48e

f7626ab0 f71fcf03 8781c4a0 f7626b74 000000df nt!CcCopyRead+0x3e7

f7626b98 f71fd079 85a69ef8 87374008 00000001 Ntfs!NtfsCommonRead+0xc14

f7626c3c 80840153 894ff670 87374008 8a70d030 Ntfs!NtfsFsdRead+0x113

f7626c50 f731dc45 8a70d030 87374008 00000000 nt!IofCallDriver+0x45

f7626c78 80840153 89528c50 87374008 87374008 fltmgr!FltpDispatch+0x6f

f7626c8c 8092b50f 87374174 87374008 8781c4a0 nt!IofCallDriver+0x45

f7626ca0 8093910f 89528c50 87374008 8781c4a0 nt!IopSynchronousServiceTail+0x10b

f7626d38 80833bdf 00000458 00000000 00000000 nt!NtReadFile+0x5d5

f7626d38 7c8285ec 00000458 00000000 00000000 nt!KiFastCallEntry+0xfc

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

042b27f4 00000000 00000000 00000000 00000000 0x7c8285ec

1: kd>

What would you recommend?

Thanks.

Ray

I have bee getting a Irql BSOD, I gve tried the info you have here but it makes no sense to me, can you help please? IRQL_NOT_LESS_OR_EQUAL (a) An attempt was made to access a pageable (or completely invalid) address at an interrupt request level (IRQL) that is too high. This is usually caused by drivers using improper addresses. If a kernel debugger is available get the stack backtrace. Arguments: Arg1: 00000005c8a93715, memory referenced Arg2: 000000000000000c, IRQL Arg3: 0000000000000001, bitfield : bit 0 : value 0 = read operation, 1 = write operation bit 3 : value 0 = not an execute operation, 1 = execute operation (only on chips which support this level of status) Arg4: fffff80001067bb6, address which referenced memory Debugging Details: ------------------ WRITE_ADDRESS: 00000005c8a93715 CURRENT_IRQL: c FAULTING_IP: nt!KiIdleLoop+76 fffff800`01067bb6 c6879500000001 mov byte ptr [rdi+95h],1 DEFAULT_BUCKET_ID: DRIVER_FAULT BUGCHECK_STR: 0xA PROCESS_NAME: Idle TRAP_FRAME: fffffadfc8e1dc20 -- (.trap 0xfffffadfc8e1dc20) NOTE: The trap frame does not contain all registers. Some register values may be zeroed or incorrect. rax=0000000000000002 rbx=fffffadfc8e1dd78 rcx=000000000000000c rdx=000000000080005d rsi=fffffadfc8a8d450 rdi=fffffadfcdaaeaf0 rip=fffff80001067bb6 rsp=fffffadfc8e1ddb0 rbp=0000000000000000 r8=000000072cb417aa r9=0000000001000000 r10=0000000000000000 r11=fffffadfc8a8d450 r12=0000000000000000 r13=0000000000000000 r14=0000000000000000 r15=0000000000000000 iopl=0 nv up ei pl zr na po nc nt!KiIdleLoop+0x76: fffff800`01067bb6 c6879500000001 mov byte ptr [rdi+95h],1 ds:4940:fffffadf`cdaaeb85=?? Resetting default scope LAST_CONTROL_TRANSFER: from fffff8000102e5b4 to fffff8000102e890 STACK_TEXT: fffffadf`c8e1da98 fffff800`0102e5b4 : 00000000`0000000a 00000005`c8a93715 00000000`0000000c 00000000`00000001 : nt!KeBugCheckEx fffffadf`c8e1daa0 fffff800`0102d547 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KiBugCheckDispatch+0x74 fffffadf`c8e1dc20 fffff800`01067bb6 : fffffadf`c8a8b180 fffffadf`c8a8b180 fffffadf`c8a93680 fffffadf`caea7a10 : nt!KiPageFault+0x207 fffffadf`c8e1ddb0 fffff800`014141d1 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KiIdleLoop+0x76 fffffadf`c8e1dde0 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KiSystemStartup+0x1bf STACK_COMMAND: kb FOLLOWUP_IP: nt!KiIdleLoop+76 fffff800`01067bb6 c6879500000001 mov byte ptr [rdi+95h],1 SYMBOL_STACK_INDEX: 3 SYMBOL_NAME: nt!KiIdleLoop+76 FOLLOWUP_NAME: MachineOwner MODULE_NAME: nt IMAGE_NAME: ntkrnlmp.exe DEBUG_FLR_IMAGE_TIMESTAMP: 48a2ca8c FAILURE_BUCKET_ID: X64_0xA_nt!KiIdleLoop+76 BUCKET_ID: X64_0xA_nt!KiIdleLoop+76 Followup: MachineOwner

hi, I ran driver verifier as mentioned but it kept rebooting the machine in a loop. I had to boot it into safe mode to abort the verification. Is this normal for Verifier to reboot the machine constantly to verify drivers ? Or is something wrong. Any advice would be much appreciated. thanx for the great series.

Driver Verifier isn't rebooting your machine. Instead, your machine is blue screening during the boot process.

There's a registry key you can set to disable verifier.exe (which I need to go look up). Your dump files should now have the real culprit in them.