CODE_CORRUPTION in crash dump

Michael_Jones · July 17, 2014, 6:03pm

I'm chasing a problem for a client where a driver for one of their cards
hangs when the system starts. I am unable to reproduce it with my
hardware (naturally). However, I do get this when start my hardware
(which is set up for debugging):

Assertion: *** DPC watchdog timeout
This is NOT a break in update time
This is most likely a BUG in an ISR
Perform a stack trace to find the culprit
The period will be doubled on continuation
Use gh to continue!!

nt! ?? ::FNODOBFM::string'+0x4f3a: fffff800030e4b75 cd2c int 2Ch

I suspect this is happening because the ISR in this driver spews a lot
of messages, and the IRQ is shared with lots of other devices, so this
driver's ISR gets called a lot, only to discover the interrupt is not
from it's device.

In any event, I did a "gn", just to see what the BSOD would look like
without Windbg hooked up (in case this is what the client is seeing).
The analyze -v is below.

I get that the bugcheck is INTERRUPT_EXCEPTION_NOT_HANDLED (since I did
a "gn" instead of a "gh"). However, I don't understand the stuff about
CODE_CURRUPTION, and the memory corruption stuff at the end of the
analyze. Can anyone enlighten me?

TIA, --mkj

0: kd> !analyze -v
*******************************************************************************
*
*
* Bugcheck Analysis
*
*
*
*******************************************************************************

INTERRUPT_EXCEPTION_NOT_HANDLED (3d)
Arguments:
Arg1: fffff80000ba0600
Arg2: 0000000000000000
Arg3: 0000000000000000
Arg4: fffff800030e4b75

Debugging Details:

CONTEXT: fffff80000ba0600 -- (.cxr 0xfffff80000ba0600)
rax=0000001cbc843b72 rbx=fffff800031ffe80 rcx=0000000000000002
rdx=0000000000000000 rsi=fffffa800e7a3b60 rdi=0000000000000001
rip=fffff800030e4b75 rsp=fffff80000ba0fe0 rbp=0000000000000001
r8=0000000000000000 r9=0000000000000000 r10=0000000000000000
r11=fffff80000ba10c0 r12=0000000000000000 r13=000000000000000a
r14=0000000000000004 r15=0000000000000001
iopl=0 nv up ei pl zr na po nc
cs=0010 ss=0018 ds=002b es=002b fs=0053 gs=002b
efl=00000246
nt! ?? ::FNODOBFM::string'+0x4f3a: fffff800030e4b75 cd2c int 2Ch
Resetting default scope

DEFAULT_BUCKET_ID: CODE_CORRUPTION

BUGCHECK_STR: 0x3D

PROCESS_NAME: LogonUI.exe

CURRENT_IRQL: d

EXCEPTION_RECORD: fffff80000ba1c58 -- (.exr 0xfffff80000ba1c58)
ExceptionAddress: fffff800030854b5 (nt!DebugPrint+0x0000000000000015)
ExceptionCode: 80000003 (Break instruction exception)
ExceptionFlags: 00000000
NumberParameters: 1
Parameter[0]: 0000000000000001

TRAP_FRAME: fffff80000ba1d00 -- (.trap 0xfffff80000ba1d00)
NOTE: The trap frame does not contain all registers.
Some register values may be zeroed or incorrect.
rax=0000000000000001 rbx=0000000000000000 rcx=fffff80000ba1f00
rdx=000000000000002f rsi=0000000000000000 rdi=0000000000000000
rip=fffff800030854b5 rsp=fffff80000ba1e98 rbp=fffff80000ba27b0
r8=0000000000000065 r9=0000000000000003 r10=0000000000000000
r11=fffff80000ba1db0 r12=0000000000000000 r13=0000000000000000
r14=0000000000000000 r15=0000000000000000
iopl=0 nv up ei ng nz ac po cy
nt!DebugPrint+0x15:
fffff800`030854b5 c3 ret
Resetting default scope

LAST_CONTROL_TRANSFER: from fffff80003097eb7 to fffff800030e4b75

STACK_TEXT:
fffff80000ba1e98 fffff800030cd675 : 0000000000000000 fffff80000ba1ea0 fffff8000313cd0c : 0000000000000000 ::FNODOBFM::string'+0xc642 fffff80000ba2150 fffff88002fbf40b fffff80000ba21c0 0000000000000000 00000000fffffffe fffff88000000040 fffff88002fc6e00 0000000000000000 : 0000ff1e00000022 fffffa800dbd4af0 fffffa800dbd4af0 : fffffa800d550120 fffffa800daca020 0000000000000000 : fffffa800d6a2a80 fffffa800d2d8d80 0000000000000000 : fffff880011289e5 fffff80000ba28a0 fffff8000300d000 : 0000000000001000 fffffa800d443ac0 fffffa800d44fa20 : fffffa800d443ac0 fffffa800d44fa20 fffffa800eadbc60 : 0000000000000000 fffffa800d4409d0 fffffa800eadbc60 : fffffa800d4409d0 fffffa800eadbc60 fffffa800eadbc60 : volmgr! ?? fffff80000ba2940 fffff88001851bce : 000000000000008b nt!IopfCompleteRequest+0x3b1 fffff80000ba2a20 fffff80003090a91 : 0000000000000000 CLASSPNP!TransferPktComplete+0x1ce fffff80000ba2aa0 fffff8800110641a : fffffa800d2d8540 nt!IopfCompleteRequest+0x3b1 fffff80000ba2b80 fffff88001106242 : fffffa800db24b80 ataport!IdeCompleteScsiIrp+0x62 fffff80000ba2bb0 fffff88001100e32 : 0000000000000002 ataport!IdeCommonCrbCompletion+0x5a fffff80000ba2be0 fffff88001109805 : fffffa800d2f31a0 ataport!IdeTranslateCompletedRequest+0x236 fffff80000ba2d10 fffff88001109104 : fffffa800d2f31a0 ataport!IdeProcessCompletedRequests+0x4d5 fffff80000ba2e40 fffff80003098b1c : fffff800031ffe80 ataport!IdePortCompletionDpc+0x1a8 fffff80000ba2f00 fffff80003090165 : 0000000000000000 nt!KiRetireDpcList+0x1bc fffff80000ba2fb0 fffff8000308ff7c : fffffa800d2d8d80 nt!KxRetireDpcList+0x5 fffff8800287a1e0 fffff800030d9453 : fffff80003089063 nt!KiDispatchInterruptContinue fffff8800287a210 fffff800030890cf : fffffa800e7a3b60 nt!KiDpcInterruptBypass+0x13 fffff8800287a220 000007fefbe71c61 : 000000000015f0a8 nt!KiChainedDispatch+0x19f 000000000015efe0 000007fefbe78ca9 : 0000000000320980 DUser!DuVisual::GetLogRect+0x296 000000000015f020 000007fefbe78dab : 0000000000000000 DUser!DuVisual::xrDrawTrivial+0x31 000000000015f080 000007fefbe78c5d : 0000000000000000 DUser!DuVisual::xrDrawTrivial+0x151 000000000015f0e0 000007fefbe79703 : 0000000000000000 DUser!DuVisual::xrDrawFull+0x929 000000000015f290 000007fefbe790d0 : 0000000000000000 DUser!DuVisual::xrDrawFull+0x97d 000000000015f440 000007fefbe78ff7 : 0000000000000000 DUser!DuVisual::xrDrawStart+0x58 000000000015f470 000007fefbe78aa7 : 0000000000000001 DUser!DuRootGadget::xrDrawTree+0x51c 000000000015f650 000007fefbe71859 : 0000000000000000 DUser!HWndContainer::xdHandleMessage+0x2b4 000000000015f950 00000000777f8971 : 0000000000000000 DUser!ExtraInfoWndProc+0x8b 000000000015f9b0 00000000777f72cb : 0000000000000000 USER32!UserCallWinProcCheckWow+0x163 000000000015fa70 00000000777f6829 : 0000000000000000 USER32!DispatchClientMessage+0xc3 000000000015fad0 0000000077931225 : 000000000000000f 000000000015fb30 00000000777f6e5a : 00000000777f6e6c ntdll!KiUserCallbackDispatcherContinue 000000000015fbb8 00000000777f6e6c : 00000000000004ff USER32!ZwUserDispatchMessage+0xa 000000000015fbc0 000007fefc7b120b : 0000000000000000 USER32!DispatchMessageWorker+0x55b 000000000015fc40 000007fefc7bb0fc : 0000000000000000 authui!CLogonFrame::DoModal+0x13d 000000000015fcc0 000007fefc7bb27f : 00000000002f31b0 authui!CLogonUI_CreateThenDoModalThenDestroy+0x299 000000000015fd20 00000000ff6354ff : 00000000002d22f0 authui!CLogonUI::DoModal+0x73 000000000015fd50 00000000ff635b06 : 0000000000000000 LogonUI!wWinMain+0xfb 000000000015fdb0 00000000776d652d : 0000000000000000 LogonUI!ParseCommandLineToStringArrayLocalAlloc+0x33a 000000000015fe70 000000007790c521 : 0000000000000000 kernel32!BaseThreadInitThunk+0xd 000000000015fea0 0000000000000000 : 0000000000000000 ntdll!RtlUserThreadStart+0x1d 0000000000000000 0000000000000000 fffff80000ba27b0 : nt!DebugPrint+0x15 fffff88002fc6e00 fffff80000ba2588 46464646463d2073 : nt! ?? : fffff88002fc6d90 : nt!DbgPrint+0x3c fffff80000ba2190 fffff88002fbfbda : fffffa8000000005 Acrmgpci!DebugPrint+0xcb [c:\clients\xembedded\src\trunk\acrmgpci\driver\driver.c @ 1630] fffff80000ba2570 fffff88002fbfd65 : 00007fff00000000 Acrmgpci!LogIsrCode+0x7a [c:\clients\xembedded\src\trunk\acrmgpci\driver\registry.c @ 665] fffff80000ba25d0 fffff88002fbde70 : fffffa800d6a2a80 Acrmgpci!RunISRCode+0xd5 [c:\clients\xembedded\src\trunk\acrmgpci\driver\registry.c @ 714] fffff80000ba26a0 fffff80003089279 : fffffa800d2d8d80 Acrmgpci!HandleInterrupt+0x30 [c:\clients\xembedded\src\trunk\acrmgpci\driver\driver.c @ 441] fffff80000ba26e0 fffff80003089058 : 000000000000001b nt!KiScanInterruptObjectList+0x69 fffff80000ba2730 fffff800036066f9 : fffff88000fc6a2c nt!KiChainedDispatch+0x128 fffff80000ba28c8 fffff88000fc6a2c : 0000000000001000 hal!KeQueryPerformanceCounter+0x5 fffff80000ba28d0 fffff88000fd9c7f : fffffa800d440b20 partmgr!PmWmiCounterIoComplete+0x2c fffff80000ba2900 fffff80003090a91 : fffffa800eadbe0b ::FNODOBFM::string'+0x2cc 0000000000000001 fffffa800d2e57d0 0000000000000000 : 0000000000000000 0000000000000000 0000000000000000 : 0000000000000001 fffffa800db24b80 0000000000000000 : ffff008004414bda fffffa800d2d8d01 0000000000000000 : 0000000000000000 0000000000000004 0000ff1e00000004 : fffffa800db24b80 0000000000000000 0000000000000000 : 0000000000000000 fffffa800d2f31a0 0000000000000000 : fffffa800dd25000 fffffa800d2f3050 fffffa800d2f3118 : fffffa800e7a3b60 0000000000000000 fffff88001108f5c : fffff96000096788 0000000025010101 fffff8800287a2a0 : fffff800030890cf fffffa800e7a3b60 fffff8800287a2a0 : fffff8800287a2a0 000000000185000f 00000000003085b0 : 000000000033f750 000000000015f030 000007fefbd8560f : 0000000000000000 0000800200000038 0000000000320a20 : 0000000000320980 0000000000000000 0000000000320c00 : 0000000000000000 0000000000000000 0000000000000000 : 0000000000000000 0000000000000000 0000000000000000 : 0000000000000000 0000000000000001 0000000000000000 : 0000000014010099 0000000000000000 0000000000000000 : 000000000033f090 0000000014010099 000004b000000640 : 0000000000000000 000004b000000000 0000000000000000 : 0000000000000000 0000000000000001 000007fefbe71785 : 000007fefbe717e4 0000000000000000 0000000000000000 : 00000000777f919b 0000000000000000 0000000000000001 : 0000000000000000 0000000000000000 0000032000006528 : USER32!_fnDWORD+0x2d 00000000000004ff 0000000000000000 0000000000000000 : 0000000000000000 0000000000000000 0000000000000001 : 0000000000000000 000007fefbe717e4 0000000000307320 : 0000000000000001 0000000000000000 0000000000000000 : 00000000002e0df0 00000000002db010 00000000002528e6 : 00000000002d22f0 0000000000000000 000000000000000b : 0000000000000000 0000000000000000 00000000ff631178 : 0000000000000000 0000000000000000 0000000000000000 : 0000000000000000 0000000000000000 0000000000000000 : 0000000000000000 0000000000000000 0000000000000000 :

STACK_COMMAND: .trap 0xfffff80000ba1d00 ; kb

CHKIMG_EXTENSION: !chkimg -lo 50 -d !nt
fffff80003090203 - nt!SwapContext_PatchXSave+2
[01:21]
fffff800030902e4 - nt!SwapContext_PatchXRstor+2 (+0xe1)
[09:29]
fffff800030904a3 - nt!EnlightenedSwapContext_PatchXSave+2 (+0x1bf)
[01:21]
fffff80003090586 - nt!EnlightenedSwapContext_PatchXRstor+2 (+0xe3)
[09:29]
4 errors : !nt (fffff80003090203-fffff80003090586)

MODULE_NAME: memory_corruption

IMAGE_NAME: memory_corruption

FOLLOWUP_NAME: memory_corruption

DEBUG_FLR_IMAGE_TIMESTAMP: 0

MEMORY_CORRUPTOR: ONE_BIT_LARGE

FAILURE_BUCKET_ID: X64_MEMORY_CORRUPTION_ONE_BIT_LARGE

BUCKET_ID: X64_MEMORY_CORRUPTION_ONE_BIT_LARGE

Followup: memory_corruption

-- mkj

//
// Michael K. Jones
// Stone Hill Consulting, LLC
// http://www.stonehill.com
//_______________________________________________

OSR_Community_User · July 17, 2014, 6:21pm

you are writting log from the isr. check if you are referencing some paged content and if you are writting too much content which over the buffer size.

===================
best regards!
zhang pei

Michael Jones 编写：

I’m chasing a problem for a client where a driver for one of their cards
hangs when the system starts. I am unable to reproduce it with my
hardware (naturally). However, I do get this when start my hardware
(which is set up for debugging):

Assertion: DPC watchdog timeout
This is NOT a break in update time
This is most likely a BUG in an ISR
Perform a stack trace to find the culprit
The period will be doubled on continuation
Use gh to continue!!

nt! ?? ::FNODOBFM::string'+0x4f3a: fffff800030e4b75 cd2c int 2Ch

I suspect this is happening because the ISR in this driver spews a lot
of messages, and the IRQ is shared with lots of other devices, so this
driver’s ISR gets called a lot, only to discover the interrupt is not
from it’s device.

In any event, I did a “gn”, just to see what the BSOD would look like
without Windbg hooked up (in case this is what the client is seeing).
The analyze -v is below.

I get that the bugcheck is INTERRUPT_EXCEPTION_NOT_HANDLED (since I did
a “gn” instead of a “gh”). However, I don’t understand the stuff about
CODE_CURRUPTION, and the memory corruption stuff at the end of the
analyze. Can anyone enlighten me?

TIA, --mkj

0: kd> !analyze -v
***************************************************************************

Bugcheck Analysis

*
*******************************************************************************

INTERRUPT_EXCEPTION_NOT_HANDLED (3d)
Arguments:
Arg1: fffff80000ba0600
Arg2: 0000000000000000
Arg3: 0000000000000000
Arg4: fffff800030e4b75

Debugging Details:
------------------

CONTEXT: fffff80000ba0600 – (.cxr 0xfffff80000ba0600)
rax=0000001cbc843b72 rbx=fffff800031ffe80 rcx=0000000000000002
rdx=0000000000000000 rsi=fffffa800e7a3b60 rdi=0000000000000001
rip=fffff800030e4b75 rsp=fffff80000ba0fe0 rbp=0000000000000001
r8=0000000000000000 r9=0000000000000000 r10=0000000000000000
r11=fffff80000ba10c0 r12=0000000000000000 r13=000000000000000a
r14=0000000000000004 r15=0000000000000001
iopl=0 nv up ei pl zr na po nc
cs=0010 ss=0018 ds=002b es=002b fs=0053 gs=002b
efl=00000246
nt! ?? ::FNODOBFM::string'+0x4f3a: fffff800030e4b75 cd2c int 2Ch
Resetting default scope

DEFAULT_BUCKET_ID: CODE_CORRUPTION

BUGCHECK_STR: 0x3D

PROCESS_NAME: LogonUI.exe

CURRENT_IRQL: d

EXCEPTION_RECORD: fffff80000ba1c58 – (.exr 0xfffff80000ba1c58)
ExceptionAddress: fffff800030854b5 (nt!DebugPrint+0x0000000000000015)
ExceptionCode: 80000003 (Break instruction exception)
ExceptionFlags: 00000000
NumberParameters: 1
Parameter[0]: 0000000000000001

TRAP_FRAME: fffff80000ba1d00 – (.trap 0xfffff80000ba1d00)
NOTE: The trap frame does not contain all registers.
Some register values may be zeroed or incorrect.
rax=0000000000000001 rbx=0000000000000000 rcx=fffff80000ba1f00
rdx=000000000000002f rsi=0000000000000000 rdi=0000000000000000
rip=fffff800030854b5 rsp=fffff80000ba1e98 rbp=fffff80000ba27b0
r8=0000000000000065 r9=0000000000000003 r10=0000000000000000
r11=fffff80000ba1db0 r12=0000000000000000 r13=0000000000000000
r14=0000000000000000 r15=0000000000000000
iopl=0 nv up ei ng nz ac po cy
nt!DebugPrint+0x15:
fffff800030854b5 c3 ret Resetting default scope LAST_CONTROL_TRANSFER: from fffff80003097eb7 to fffff800030e4b75 STACK_TEXT: fffff80000ba1e98 fffff800030cd675 : 0000000000000000
0000000000000000 0000000000000000 fffff80000ba27b0 : nt!DebugPrint+0x15 fffff80000ba1ea0 fffff8000313cd0c : 0000000000000000
fffff88002fc6e00 fffff80000ba2588 46464646463d2073 : nt! ?? ::FNODOBFM::string’+0xc642
fffff80000ba2150 fffff88002fbf40b : fffff88002fc6d90 fffff80000ba21c0 0000000000000000 00000000fffffffe : nt!DbgPrint+0x3c
fffff80000ba2190 fffff88002fbfbda : fffffa8000000005 fffff88000000040 fffff88002fc6e00 0000000000000000 :
Acrmgpci!DebugPrint+0xcb
[c:\clients\xembedded\src\trunk\acrmgpci\driver\driver.c @ 1630]
fffff80000ba2570 fffff88002fbfd65 : 00007fff00000000 0000ff1e00000022 fffffa800dbd4af0 fffffa800dbd4af0 :
Acrmgpci!LogIsrCode+0x7a
[c:\clients\xembedded\src\trunk\acrmgpci\driver\registry.c @ 665]
fffff80000ba25d0 fffff88002fbde70 : fffffa800d6a2a80 fffffa800d550120 fffffa800daca020 0000000000000000 :
Acrmgpci!RunISRCode+0xd5
[c:\clients\xembedded\src\trunk\acrmgpci\driver\registry.c @ 714]
fffff80000ba26a0 fffff80003089279 : fffffa800d2d8d80 fffffa800d6a2a80 fffffa800d2d8d80 0000000000000000 :
Acrmgpci!HandleInterrupt+0x30
[c:\clients\xembedded\src\trunk\acrmgpci\driver\driver.c @ 441]
fffff80000ba26e0 fffff80003089058 : 000000000000001b fffff880011289e5 fffff80000ba28a0 fffff8000300d000 :
nt!KiScanInterruptObjectList+0x69
fffff80000ba2730 fffff800036066f9 : fffff88000fc6a2c 0000000000001000 fffffa800d443ac0 fffffa800d44fa20 :
nt!KiChainedDispatch+0x128
fffff80000ba28c8 fffff88000fc6a2c : 0000000000001000 fffffa800d443ac0 fffffa800d44fa20 fffffa800eadbc60 :
hal!KeQueryPerformanceCounter+0x5
fffff80000ba28d0 fffff88000fd9c7f : fffffa800d440b20 0000000000000000 fffffa800d4409d0 fffffa800eadbc60 :
partmgr!PmWmiCounterIoComplete+0x2c
fffff80000ba2900 fffff80003090a91 : fffffa800eadbe0b fffffa800d4409d0 fffffa800eadbc60 fffffa800eadbc60 : volmgr! ??
::FNODOBFM::string'+0x2cc fffff80000ba2940 fffff88001851bce : 000000000000008b
0000000000000001 fffffa800d2e57d0 0000000000000000 : nt!IopfCompleteRequest+0x3b1 fffff80000ba2a20 fffff80003090a91 : 0000000000000000
0000000000000000 0000000000000000 0000000000000000 : CLASSPNP!TransferPktComplete+0x1ce fffff80000ba2aa0 fffff8800110641a : fffffa800d2d8540
0000000000000001 fffffa800db24b80 0000000000000000 : nt!IopfCompleteRequest+0x3b1 fffff80000ba2b80 fffff88001106242 : fffffa800db24b80
ffff008004414bda fffffa800d2d8d01 0000000000000000 : ataport!IdeCompleteScsiIrp+0x62 fffff80000ba2bb0 fffff88001100e32 : 0000000000000002
0000000000000000 0000000000000004 0000ff1e00000004 : ataport!IdeCommonCrbCompletion+0x5a fffff80000ba2be0 fffff88001109805 : fffffa800d2f31a0
fffffa800db24b80 0000000000000000 0000000000000000 : ataport!IdeTranslateCompletedRequest+0x236 fffff80000ba2d10 fffff88001109104 : fffffa800d2f31a0
0000000000000000 fffffa800d2f31a0 0000000000000000 : ataport!IdeProcessCompletedRequests+0x4d5 fffff80000ba2e40 fffff80003098b1c : fffff800031ffe80
fffffa800dd25000 fffffa800d2f3050 fffffa800d2f3118 : ataport!IdePortCompletionDpc+0x1a8 fffff80000ba2f00 fffff80003090165 : 0000000000000000
fffffa800e7a3b60 0000000000000000 fffff88001108f5c : nt!KiRetireDpcList+0x1bc fffff80000ba2fb0 fffff8000308ff7c : fffffa800d2d8d80
fffff96000096788 0000000025010101 fffff8800287a2a0 : nt!KxRetireDpcList+0x5 fffff8800287a1e0 fffff800030d9453 : fffff80003089063
fffff800030890cf fffffa800e7a3b60 fffff8800287a2a0 : nt!KiDispatchInterruptContinue fffff8800287a210 fffff800030890cf : fffffa800e7a3b60
fffff8800287a2a0 000000000185000f 00000000003085b0 : nt!KiDpcInterruptBypass+0x13 fffff8800287a220 000007fefbe71c61 : 000000000015f0a8
000000000033f750 000000000015f030 000007fefbd8560f : nt!KiChainedDispatch+0x19f 000000000015efe0 000007fefbe78ca9 : 0000000000320980
0000000000000000 0000800200000038 0000000000320a20 : DUser!DuVisual::GetLogRect+0x296 000000000015f020 000007fefbe78dab : 0000000000000000
0000000000320980 0000000000000000 0000000000320c00 : DUser!DuVisual::xrDrawTrivial+0x31 000000000015f080 000007fefbe78c5d : 0000000000000000
0000000000000000 0000000000000000 0000000000000000 : DUser!DuVisual::xrDrawTrivial+0x151 000000000015f0e0 000007fefbe79703 : 0000000000000000
0000000000000000 0000000000000000 0000000000000000 : DUser!DuVisual::xrDrawFull+0x929 000000000015f290 000007fefbe790d0 : 0000000000000000
0000000000000000 0000000000000001 0000000000000000 : DUser!DuVisual::xrDrawFull+0x97d 000000000015f440 000007fefbe78ff7 : 0000000000000000
0000000014010099 0000000000000000 0000000000000000 : DUser!DuVisual::xrDrawStart+0x58 000000000015f470 000007fefbe78aa7 : 0000000000000001
000000000033f090 0000000014010099 000004b000000640 : DUser!DuRootGadget::xrDrawTree+0x51c 000000000015f650 000007fefbe71859 : 0000000000000000
0000000000000000 000004b000000000 0000000000000000 : DUser!HWndContainer::xdHandleMessage+0x2b4 000000000015f950 00000000777f8971 : 0000000000000000
0000000000000000 0000000000000001 000007fefbe71785 : DUser!ExtraInfoWndProc+0x8b 000000000015f9b0 00000000777f72cb : 0000000000000000
000007fefbe717e4 0000000000000000 0000000000000000 : USER32!UserCallWinProcCheckWow+0x163 000000000015fa70 00000000777f6829 : 0000000000000000
00000000777f919b 0000000000000000 0000000000000001 : USER32!DispatchClientMessage+0xc3 000000000015fad0 0000000077931225 : 000000000000000f
0000000000000000 0000000000000000 0000032000006528 : USER32!_fnDWORD+0x2d 000000000015fb30 00000000777f6e5a : 00000000777f6e6c
00000000000004ff 0000000000000000 0000000000000000 : ntdll!KiUserCallbackDispatcherContinue 000000000015fbb8 00000000777f6e6c : 00000000000004ff
0000000000000000 0000000000000000 0000000000000001 : USER32!ZwUserDispatchMessage+0xa 000000000015fbc0 000007fefc7b120b : 0000000000000000
0000000000000000 000007fefbe717e4 0000000000307320 : USER32!DispatchMessageWorker+0x55b 000000000015fc40 000007fefc7bb0fc : 0000000000000000
0000000000000001 0000000000000000 0000000000000000 : authui!CLogonFrame::DoModal+0x13d 000000000015fcc0 000007fefc7bb27f : 00000000002f31b0
00000000002e0df0 00000000002db010 00000000002528e6 : authui!CLogonUI_CreateThenDoModalThenDestroy+0x299 000000000015fd20 00000000ff6354ff : 00000000002d22f0
00000000002d22f0 0000000000000000 000000000000000b : authui!CLogonUI::DoModal+0x73 000000000015fd50 00000000ff635b06 : 0000000000000000
0000000000000000 0000000000000000 00000000ff631178 : LogonUI!wWinMain+0xfb 000000000015fdb0 00000000776d652d : 0000000000000000
0000000000000000 0000000000000000 0000000000000000 : LogonUI!ParseCommandLineToStringArrayLocalAlloc+0x33a 000000000015fe70 000000007790c521 : 0000000000000000
0000000000000000 0000000000000000 0000000000000000 : kernel32!BaseThreadInitThunk+0xd 000000000015fea0 0000000000000000 : 0000000000000000
0000000000000000 0000000000000000 00000000`00000000 :
ntdll!RtlUserThreadStart+0x1d

STACK_COMMAND: .trap 0xfffff80000ba1d00 ; kb

CHKIMG_EXTENSION: !chkimg -lo 50 -d !nt
fffff80003090203 - nt!SwapContext_PatchXSave+2
[01:21]
fffff800030902e4 - nt!SwapContext_PatchXRstor+2 (+0xe1)
[09:29]
fffff800030904a3 - nt!EnlightenedSwapContext_PatchXSave+2 (+0x1bf)
[01:21]
fffff80003090586 - nt!EnlightenedSwapContext_PatchXRstor+2 (+0xe3)
[09:29]
4 errors : !nt (fffff80003090203-fffff80003090586)

MODULE_NAME: memory_corruption

IMAGE_NAME: memory_corruption

FOLLOWUP_NAME: memory_corruption

DEBUG_FLR_IMAGE_TIMESTAMP: 0

MEMORY_CORRUPTOR: ONE_BIT_LARGE

FAILURE_BUCKET_ID: X64_MEMORY_CORRUPTION_ONE_BIT_LARGE

BUCKET_ID: X64_MEMORY_CORRUPTION_ONE_BIT_LARGE

Followup: memory_corruption
---------

– mkj

//
// Michael K. Jones
// Stone Hill Consulting, LLC
// http://www.stonehill.com
//

—
NTDEV is sponsored by OSR

Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev

OSR is HIRING!! See http://www.osr.com/careers

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

Michael_Jones · July 17, 2014, 6:36pm

Thanks for your response!

The buffer used to format the trace string is on the stack, so not paged
memory. The code uses RtlStringCbVPrintfA (and checks the return
value), so not a problem with buffer overflow happening.

I’m not too keen on the fact that the buffer is on the stack; however, I
don’t believe it’s overflowing the stack. I’ve had that problem in the
past (with other drivers), and IIRC it’s a pretty explicit bug check,
which I’m not seeing in this case. Isn’t there a guard page after
(well, before) the stack?

I will probably change that buffer to not occupy stack space; however,
it’s not a trivial change since I believe it was originally written that
way in order to avoid traces from multiple threads stepping on each
other. So I’m trying to avoid making that sort of change until I get a
better handle on the bug I’m currently chasing.

Cheers,

–mkj

On 7/17/2014 6:20 PM, zhang pei wrote:

you are writting log from the isr. check if you are referencing some paged content and if you are writting too much content which over the buffer size.

===================
best regards!
zhang pei

Michael Jones ç¼–å†™ï¼š
>
> I’m chasing a problem for a client where a driver for one of their cards
> hangs when the system starts. I am unable to reproduce it with my
> hardware (naturally). However, I do get this when start my hardware
> (which is set up for debugging):
>
> Assertion: DPC watchdog timeout
> This is NOT a break in update time
> This is most likely a BUG in an ISR
> Perform a stack trace to find the culprit
> The period will be doubled on continuation
> Use gh to continue!!
>
> nt! ?? ::FNODOBFM::string'+0x4f3a: > fffff800030e4b75 cd2c int 2Ch
>
> I suspect this is happening because the ISR in this driver spews a lot
> of messages, and the IRQ is shared with lots of other devices, so this
> driver’s ISR gets called a lot, only to discover the interrupt is not
> from it’s device.
>
> In any event, I did a “gn”, just to see what the BSOD would look like
> without Windbg hooked up (in case this is what the client is seeing).
> The analyze -v is below.
>
> I get that the bugcheck is INTERRUPT_EXCEPTION_NOT_HANDLED (since I did
> a “gn” instead of a “gh”). However, I don’t understand the stuff about
> CODE_CURRUPTION, and the memory corruption stuff at the end of the
> analyze. Can anyone enlighten me?
>
> TIA, --mkj
>
>
>
> 0: kd> !analyze -v
>****************************************************************************
> *
> *
> * Bugcheck Analysis
> *
> *
> *
> *******************************************************************************
>
> INTERRUPT_EXCEPTION_NOT_HANDLED (3d)
> Arguments:
> Arg1: fffff80000ba0600
> Arg2: 0000000000000000
> Arg3: 0000000000000000
> Arg4: fffff800030e4b75
>
> Debugging Details:
> ------------------
>
>
> CONTEXT: fffff80000ba0600 – (.cxr 0xfffff80000ba0600)
> rax=0000001cbc843b72 rbx=fffff800031ffe80 rcx=0000000000000002
> rdx=0000000000000000 rsi=fffffa800e7a3b60 rdi=0000000000000001
> rip=fffff800030e4b75 rsp=fffff80000ba0fe0 rbp=0000000000000001
> r8=0000000000000000 r9=0000000000000000 r10=0000000000000000
> r11=fffff80000ba10c0 r12=0000000000000000 r13=000000000000000a
> r14=0000000000000004 r15=0000000000000001
> iopl=0 nv up ei pl zr na po nc
> cs=0010 ss=0018 ds=002b es=002b fs=0053 gs=002b
> efl=00000246
> nt! ?? ::FNODOBFM::string'+0x4f3a: > fffff800030e4b75 cd2c int 2Ch
> Resetting default scope
>
> DEFAULT_BUCKET_ID: CODE_CORRUPTION
>
> BUGCHECK_STR: 0x3D
>
> PROCESS_NAME: LogonUI.exe
>
> CURRENT_IRQL: d
>
> EXCEPTION_RECORD: fffff80000ba1c58 – (.exr 0xfffff80000ba1c58)
> ExceptionAddress: fffff800030854b5 (nt!DebugPrint+0x0000000000000015)
> ExceptionCode: 80000003 (Break instruction exception)
> ExceptionFlags: 00000000
> NumberParameters: 1
> Parameter[0]: 0000000000000001
>
> TRAP_FRAME: fffff80000ba1d00 – (.trap 0xfffff80000ba1d00)
> NOTE: The trap frame does not contain all registers.
> Some register values may be zeroed or incorrect.
> rax=0000000000000001 rbx=0000000000000000 rcx=fffff80000ba1f00
> rdx=000000000000002f rsi=0000000000000000 rdi=0000000000000000
> rip=fffff800030854b5 rsp=fffff80000ba1e98 rbp=fffff80000ba27b0
> r8=0000000000000065 r9=0000000000000003 r10=0000000000000000
> r11=fffff80000ba1db0 r12=0000000000000000 r13=0000000000000000
> r14=0000000000000000 r15=0000000000000000
> iopl=0 nv up ei ng nz ac po cy
> nt!DebugPrint+0x15:
> fffff800030854b5 c3 ret > Resetting default scope > > LAST_CONTROL_TRANSFER: from fffff80003097eb7 to fffff800030e4b75 > > STACK_TEXT: > fffff80000ba1e98 fffff800030cd675 : 0000000000000000
> 0000000000000000 0000000000000000 fffff80000ba27b0 : nt!DebugPrint+0x15 > fffff80000ba1ea0 fffff8000313cd0c : 0000000000000000
> fffff88002fc6e00 fffff80000ba2588 46464646463d2073 : nt! ?? > ::FNODOBFM::string’+0xc642
> fffff80000ba2150 fffff88002fbf40b : fffff88002fc6d90 > fffff80000ba21c0 0000000000000000 00000000fffffffe : nt!DbgPrint+0x3c
> fffff80000ba2190 fffff88002fbfbda : fffffa8000000005 > fffff88000000040 fffff88002fc6e00 0000000000000000 :
> Acrmgpci!DebugPrint+0xcb
> [c:\clients\xembedded\src\trunk\acrmgpci\driver\driver.c @ 1630]
> fffff80000ba2570 fffff88002fbfd65 : 00007fff00000000 > 0000ff1e00000022 fffffa800dbd4af0 fffffa800dbd4af0 :
> Acrmgpci!LogIsrCode+0x7a
> [c:\clients\xembedded\src\trunk\acrmgpci\driver\registry.c @ 665]
> fffff80000ba25d0 fffff88002fbde70 : fffffa800d6a2a80 > fffffa800d550120 fffffa800daca020 0000000000000000 :
> Acrmgpci!RunISRCode+0xd5
> [c:\clients\xembedded\src\trunk\acrmgpci\driver\registry.c @ 714]
> fffff80000ba26a0 fffff80003089279 : fffffa800d2d8d80 > fffffa800d6a2a80 fffffa800d2d8d80 0000000000000000 :
> Acrmgpci!HandleInterrupt+0x30
> [c:\clients\xembedded\src\trunk\acrmgpci\driver\driver.c @ 441]
> fffff80000ba26e0 fffff80003089058 : 000000000000001b > fffff880011289e5 fffff80000ba28a0 fffff8000300d000 :
> nt!KiScanInterruptObjectList+0x69
> fffff80000ba2730 fffff800036066f9 : fffff88000fc6a2c > 0000000000001000 fffffa800d443ac0 fffffa800d44fa20 :
> nt!KiChainedDispatch+0x128
> fffff80000ba28c8 fffff88000fc6a2c : 0000000000001000 > fffffa800d443ac0 fffffa800d44fa20 fffffa800eadbc60 :
> hal!KeQueryPerformanceCounter+0x5
> fffff80000ba28d0 fffff88000fd9c7f : fffffa800d440b20 > 0000000000000000 fffffa800d4409d0 fffffa800eadbc60 :
> partmgr!PmWmiCounterIoComplete+0x2c
> fffff80000ba2900 fffff80003090a91 : fffffa800eadbe0b > fffffa800d4409d0 fffffa800eadbc60 fffffa800eadbc60 : volmgr! ??
> ::FNODOBFM::string'+0x2cc > fffff80000ba2940 fffff88001851bce : 000000000000008b
> 0000000000000001 fffffa800d2e57d0 0000000000000000 : > nt!IopfCompleteRequest+0x3b1 > fffff80000ba2a20 fffff80003090a91 : 0000000000000000
> 0000000000000000 0000000000000000 0000000000000000 : > CLASSPNP!TransferPktComplete+0x1ce > fffff80000ba2aa0 fffff8800110641a : fffffa800d2d8540
> 0000000000000001 fffffa800db24b80 0000000000000000 : > nt!IopfCompleteRequest+0x3b1 > fffff80000ba2b80 fffff88001106242 : fffffa800db24b80
> ffff008004414bda fffffa800d2d8d01 0000000000000000 : > ataport!IdeCompleteScsiIrp+0x62 > fffff80000ba2bb0 fffff88001100e32 : 0000000000000002
> 0000000000000000 0000000000000004 0000ff1e00000004 : > ataport!IdeCommonCrbCompletion+0x5a > fffff80000ba2be0 fffff88001109805 : fffffa800d2f31a0
> fffffa800db24b80 0000000000000000 0000000000000000 : > ataport!IdeTranslateCompletedRequest+0x236 > fffff80000ba2d10 fffff88001109104 : fffffa800d2f31a0
> 0000000000000000 fffffa800d2f31a0 0000000000000000 : > ataport!IdeProcessCompletedRequests+0x4d5 > fffff80000ba2e40 fffff80003098b1c : fffff800031ffe80
> fffffa800dd25000 fffffa800d2f3050 fffffa800d2f3118 : > ataport!IdePortCompletionDpc+0x1a8 > fffff80000ba2f00 fffff80003090165 : 0000000000000000
> fffffa800e7a3b60 0000000000000000 fffff88001108f5c : > nt!KiRetireDpcList+0x1bc > fffff80000ba2fb0 fffff8000308ff7c : fffffa800d2d8d80
> fffff96000096788 0000000025010101 fffff8800287a2a0 : > nt!KxRetireDpcList+0x5 > fffff8800287a1e0 fffff800030d9453 : fffff80003089063
> fffff800030890cf fffffa800e7a3b60 fffff8800287a2a0 : > nt!KiDispatchInterruptContinue > fffff8800287a210 fffff800030890cf : fffffa800e7a3b60
> fffff8800287a2a0 000000000185000f 00000000003085b0 : > nt!KiDpcInterruptBypass+0x13 > fffff8800287a220 000007fefbe71c61 : 000000000015f0a8
> 000000000033f750 000000000015f030 000007fefbd8560f : > nt!KiChainedDispatch+0x19f > 000000000015efe0 000007fefbe78ca9 : 0000000000320980
> 0000000000000000 0000800200000038 0000000000320a20 : > DUser!DuVisual::GetLogRect+0x296 > 000000000015f020 000007fefbe78dab : 0000000000000000
> 0000000000320980 0000000000000000 0000000000320c00 : > DUser!DuVisual::xrDrawTrivial+0x31 > 000000000015f080 000007fefbe78c5d : 0000000000000000
> 0000000000000000 0000000000000000 0000000000000000 : > DUser!DuVisual::xrDrawTrivial+0x151 > 000000000015f0e0 000007fefbe79703 : 0000000000000000
> 0000000000000000 0000000000000000 0000000000000000 : > DUser!DuVisual::xrDrawFull+0x929 > 000000000015f290 000007fefbe790d0 : 0000000000000000
> 0000000000000000 0000000000000001 0000000000000000 : > DUser!DuVisual::xrDrawFull+0x97d > 000000000015f440 000007fefbe78ff7 : 0000000000000000
> 0000000014010099 0000000000000000 0000000000000000 : > DUser!DuVisual::xrDrawStart+0x58 > 000000000015f470 000007fefbe78aa7 : 0000000000000001
> 000000000033f090 0000000014010099 000004b000000640 : > DUser!DuRootGadget::xrDrawTree+0x51c > 000000000015f650 000007fefbe71859 : 0000000000000000
> 0000000000000000 000004b000000000 0000000000000000 : > DUser!HWndContainer::xdHandleMessage+0x2b4 > 000000000015f950 00000000777f8971 : 0000000000000000
> 0000000000000000 0000000000000001 000007fefbe71785 : > DUser!ExtraInfoWndProc+0x8b > 000000000015f9b0 00000000777f72cb : 0000000000000000
> 000007fefbe717e4 0000000000000000 0000000000000000 : > USER32!UserCallWinProcCheckWow+0x163 > 000000000015fa70 00000000777f6829 : 0000000000000000
> 00000000777f919b 0000000000000000 0000000000000001 : > USER32!DispatchClientMessage+0xc3 > 000000000015fad0 0000000077931225 : 000000000000000f
> 0000000000000000 0000000000000000 0000032000006528 : USER32!_fnDWORD+0x2d > 000000000015fb30 00000000777f6e5a : 00000000777f6e6c
> 00000000000004ff 0000000000000000 0000000000000000 : > ntdll!KiUserCallbackDispatcherContinue > 000000000015fbb8 00000000777f6e6c : 00000000000004ff
> 0000000000000000 0000000000000000 0000000000000001 : > USER32!ZwUserDispatchMessage+0xa > 000000000015fbc0 000007fefc7b120b : 0000000000000000
> 0000000000000000 000007fefbe717e4 0000000000307320 : > USER32!DispatchMessageWorker+0x55b > 000000000015fc40 000007fefc7bb0fc : 0000000000000000
> 0000000000000001 0000000000000000 0000000000000000 : > authui!CLogonFrame::DoModal+0x13d > 000000000015fcc0 000007fefc7bb27f : 00000000002f31b0
> 00000000002e0df0 00000000002db010 00000000002528e6 : > authui!CLogonUI_CreateThenDoModalThenDestroy+0x299 > 000000000015fd20 00000000ff6354ff : 00000000002d22f0
> 00000000002d22f0 0000000000000000 000000000000000b : > authui!CLogonUI::DoModal+0x73 > 000000000015fd50 00000000ff635b06 : 0000000000000000
> 0000000000000000 0000000000000000 00000000ff631178 : > LogonUI!wWinMain+0xfb > 000000000015fdb0 00000000776d652d : 0000000000000000
> 0000000000000000 0000000000000000 0000000000000000 : > LogonUI!ParseCommandLineToStringArrayLocalAlloc+0x33a > 000000000015fe70 000000007790c521 : 0000000000000000
> 0000000000000000 0000000000000000 0000000000000000 : > kernel32!BaseThreadInitThunk+0xd > 000000000015fea0 0000000000000000 : 0000000000000000
> 0000000000000000 0000000000000000 00000000`00000000 :
> ntdll!RtlUserThreadStart+0x1d
>
>
> STACK_COMMAND: .trap 0xfffff80000ba1d00 ; kb
>
> CHKIMG_EXTENSION: !chkimg -lo 50 -d !nt
> fffff80003090203 - nt!SwapContext_PatchXSave+2
> [01:21]
> fffff800030902e4 - nt!SwapContext_PatchXRstor+2 (+0xe1)
> [09:29]
> fffff800030904a3 - nt!EnlightenedSwapContext_PatchXSave+2 (+0x1bf)
> [01:21]
> fffff80003090586 - nt!EnlightenedSwapContext_PatchXRstor+2 (+0xe3)
> [09:29]
> 4 errors : !nt (fffff80003090203-fffff80003090586)
>
> MODULE_NAME: memory_corruption
>
> IMAGE_NAME: memory_corruption
>
> FOLLOWUP_NAME: memory_corruption
>
> DEBUG_FLR_IMAGE_TIMESTAMP: 0
>
> MEMORY_CORRUPTOR: ONE_BIT_LARGE
>
> FAILURE_BUCKET_ID: X64_MEMORY_CORRUPTION_ONE_BIT_LARGE
>
> BUCKET_ID: X64_MEMORY_CORRUPTION_ONE_BIT_LARGE
>
> Followup: memory_corruption
> ---------
>
> – mkj
>
> //
> // Michael K. Jones
> // Stone Hill Consulting, LLC
> // http://www.stonehill.com
> //
>
> —
> NTDEV is sponsored by OSR
>
> Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev
>
> OSR is HIRING!! See http://www.osr.com/careers
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
>

–
– mkj

//
// Michael K. Jones
// Stone Hill Consulting, LLC
// http://www.stonehill.com
//

Tim_Roberts · July 17, 2014, 6:54pm

Michael Jones wrote:

I suspect this is happening because the ISR in this driver spews a lot
of messages, and the IRQ is shared with lots of other devices, so this
driver’s ISR gets called a lot, only to discover the interrupt is not
from it’s device.

I keep having to re-learn the lesson of how large the performance
penalty of DbgPrint is, especially because I work in real-time systems
like audio and video. As a rule, I almost never do any DbgPrints in the
ISR. I don’t mind so much in a DPC.

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

OSR_Community_User · July 17, 2014, 7:09pm

what you do in the isr? i advice you finish it quickly and leave data process in dpc. i’m not sure what the dpc timeout is caused by, but check your code and make isr as simple as possible.

===================
best regards!
zhang pei

Michael Jones 编写：

Thanks for your response!

The buffer used to format the trace string is on the stack, so not paged
memory. The code uses RtlStringCbVPrintfA (and checks the return
value), so not a problem with buffer overflow happening.

I’m not too keen on the fact that the buffer is on the stack; however, I
don’t believe it’s overflowing the stack. I’ve had that problem in the
past (with other drivers), and IIRC it’s a pretty explicit bug check,
which I’m not seeing in this case. Isn’t there a guard page after
(well, before) the stack?

I will probably change that buffer to not occupy stack space; however,
it’s not a trivial change since I believe it was originally written that
way in order to avoid traces from multiple threads stepping on each
other. So I’m trying to avoid making that sort of change until I get a
better handle on the bug I’m currently chasing.

Cheers,

–mkj

On 7/17/2014 6:20 PM, zhang pei wrote:
> you are writting log from the isr. check if you are referencing some paged content and if you are writting too much content which over the buffer size.
>
>
>
> ===================
> best regards!
> zhang pei
>
>
> Michael Jones 编写：
>
> I’m chasing a problem for a client where a driver for one of their cards
> hangs when the system starts. I am unable to reproduce it with my
> hardware (naturally). However, I do get this when start my hardware
> (which is set up for debugging):
>
> Assertion: DPC watchdog timeout
> This is NOT a break in update time
> This is most likely a BUG in an ISR
> Perform a stack trace to find the culprit
> The period will be doubled on continuation
> Use gh to continue!!
>
> nt! ?? ::FNODOBFM::string'+0x4f3a: > fffff800030e4b75 cd2c int 2Ch
>
> I suspect this is happening because the ISR in this driver spews a lot
> of messages, and the IRQ is shared with lots of other devices, so this
> driver’s ISR gets called a lot, only to discover the interrupt is not
> from it’s device.
>
> In any event, I did a “gn”, just to see what the BSOD would look like
> without Windbg hooked up (in case this is what the client is seeing).
> The analyze -v is below.
>
> I get that the bugcheck is INTERRUPT_EXCEPTION_NOT_HANDLED (since I did
> a “gn” instead of a “gh”). However, I don’t understand the stuff about
> CODE_CURRUPTION, and the memory corruption stuff at the end of the
> analyze. Can anyone enlighten me?
>
> TIA, --mkj
>
>
>
> 0: kd> !analyze -v
>****************************************************************************
> *
> *
> * Bugcheck Analysis
> *
> *
> *
> *******************************************************************************
>
> INTERRUPT_EXCEPTION_NOT_HANDLED (3d)
> Arguments:
> Arg1: fffff80000ba0600
> Arg2: 0000000000000000
> Arg3: 0000000000000000
> Arg4: fffff800030e4b75
>
> Debugging Details:
> ------------------
>
>
> CONTEXT: fffff80000ba0600 – (.cxr 0xfffff80000ba0600)
> rax=0000001cbc843b72 rbx=fffff800031ffe80 rcx=0000000000000002
> rdx=0000000000000000 rsi=fffffa800e7a3b60 rdi=0000000000000001
> rip=fffff800030e4b75 rsp=fffff80000ba0fe0 rbp=0000000000000001
> r8=0000000000000000 r9=0000000000000000 r10=0000000000000000
> r11=fffff80000ba10c0 r12=0000000000000000 r13=000000000000000a
> r14=0000000000000004 r15=0000000000000001
> iopl=0 nv up ei pl zr na po nc
> cs=0010 ss=0018 ds=002b es=002b fs=0053 gs=002b
> efl=00000246
> nt! ?? ::FNODOBFM::string'+0x4f3a: > fffff800030e4b75 cd2c int 2Ch
> Resetting default scope
>
> DEFAULT_BUCKET_ID: CODE_CORRUPTION
>
> BUGCHECK_STR: 0x3D
>
> PROCESS_NAME: LogonUI.exe
>
> CURRENT_IRQL: d
>
> EXCEPTION_RECORD: fffff80000ba1c58 – (.exr 0xfffff80000ba1c58)
> ExceptionAddress: fffff800030854b5 (nt!DebugPrint+0x0000000000000015)
> ExceptionCode: 80000003 (Break instruction exception)
> ExceptionFlags: 00000000
> NumberParameters: 1
> Parameter[0]: 0000000000000001
>
> TRAP_FRAME: fffff80000ba1d00 – (.trap 0xfffff80000ba1d00)
> NOTE: The trap frame does not contain all registers.
> Some register values may be zeroed or incorrect.
> rax=0000000000000001 rbx=0000000000000000 rcx=fffff80000ba1f00
> rdx=000000000000002f rsi=0000000000000000 rdi=0000000000000000
> rip=fffff800030854b5 rsp=fffff80000ba1e98 rbp=fffff80000ba27b0
> r8=0000000000000065 r9=0000000000000003 r10=0000000000000000
> r11=fffff80000ba1db0 r12=0000000000000000 r13=0000000000000000
> r14=0000000000000000 r15=0000000000000000
> iopl=0 nv up ei ng nz ac po cy
> nt!DebugPrint+0x15:
> fffff800030854b5 c3 ret > Resetting default scope > > LAST_CONTROL_TRANSFER: from fffff80003097eb7 to fffff800030e4b75 > > STACK_TEXT: > fffff80000ba1e98 fffff800030cd675 : 0000000000000000
> 0000000000000000 0000000000000000 fffff80000ba27b0 : nt!DebugPrint+0x15 > fffff80000ba1ea0 fffff8000313cd0c : 0000000000000000
> fffff88002fc6e00 fffff80000ba2588 46464646463d2073 : nt! ?? > ::FNODOBFM::string’+0xc642
> fffff80000ba2150 fffff88002fbf40b : fffff88002fc6d90 > fffff80000ba21c0 0000000000000000 00000000fffffffe : nt!DbgPrint+0x3c
> fffff80000ba2190 fffff88002fbfbda : fffffa8000000005 > fffff88000000040 fffff88002fc6e00 0000000000000000 :
> Acrmgpci!DebugPrint+0xcb
> [c:\clients\xembedded\src\trunk\acrmgpci\driver\driver.c @ 1630]
> fffff80000ba2570 fffff88002fbfd65 : 00007fff00000000 > 0000ff1e00000022 fffffa800dbd4af0 fffffa800dbd4af0 :
> Acrmgpci!LogIsrCode+0x7a
> [c:\clients\xembedded\src\trunk\acrmgpci\driver\registry.c @ 665]
> fffff80000ba25d0 fffff88002fbde70 : fffffa800d6a2a80 > fffffa800d550120 fffffa800daca020 0000000000000000 :
> Acrmgpci!RunISRCode+0xd5
> [c:\clients\xembedded\src\trunk\acrmgpci\driver\registry.c @ 714]
> fffff80000ba26a0 fffff80003089279 : fffffa800d2d8d80 > fffffa800d6a2a80 fffffa800d2d8d80 0000000000000000 :
> Acrmgpci!HandleInterrupt+0x30
> [c:\clients\xembedded\src\trunk\acrmgpci\driver\driver.c @ 441]
> fffff80000ba26e0 fffff80003089058 : 000000000000001b > fffff880011289e5 fffff80000ba28a0 fffff8000300d000 :
> nt!KiScanInterruptObjectList+0x69
> fffff80000ba2730 fffff800036066f9 : fffff88000fc6a2c > 0000000000001000 fffffa800d443ac0 fffffa800d44fa20 :
> nt!KiChainedDispatch+0x128
> fffff80000ba28c8 fffff88000fc6a2c : 0000000000001000 > fffffa800d443ac0 fffffa800d44fa20 fffffa800eadbc60 :
> hal!KeQueryPerformanceCounter+0x5
> fffff80000ba28d0 fffff88000fd9c7f : fffffa800d440b20 > 0000000000000000 fffffa800d4409d0 fffffa800eadbc60 :
> partmgr!PmWmiCounterIoComplete+0x2c
> fffff80000ba2900 fffff80003090a91 : fffffa800eadbe0b > fffffa800d4409d0 fffffa800eadbc60 fffffa800eadbc60 : volmgr! ??
> ::FNODOBFM::string'+0x2cc > fffff80000ba2940 fffff88001851bce : 000000000000008b
> 0000000000000001 fffffa800d2e57d0 0000000000000000 : > nt!IopfCompleteRequest+0x3b1 > fffff80000ba2a20 fffff80003090a91 : 0000000000000000
> 0000000000000000 0000000000000000 0000000000000000 : > CLASSPNP!TransferPktComplete+0x1ce > fffff80000ba2aa0 fffff8800110641a : fffffa800d2d8540
> 0000000000000001 fffffa800db24b80 0000000000000000 : > nt!IopfCompleteRequest+0x3b1 > fffff80000ba2b80 fffff88001106242 : fffffa800db24b80
> ffff008004414bda fffffa800d2d8d01 0000000000000000 : > ataport!IdeCompleteScsiIrp+0x62 > fffff80000ba2bb0 fffff88001100e32 : 0000000000000002
> 0000000000000000 0000000000000004 0000ff1e00000004 : > ataport!IdeCommonCrbCompletion+0x5a > fffff80000ba2be0 fffff88001109805 : fffffa800d2f31a0
> fffffa800db24b80 0000000000000000 0000000000000000 : > ataport!IdeTranslateCompletedRequest+0x236 > fffff80000ba2d10 fffff88001109104 : fffffa800d2f31a0
> 0000000000000000 fffffa800d2f31a0 0000000000000000 : > ataport!IdeProcessCompletedRequests+0x4d5 > fffff80000ba2e40 fffff80003098b1c : fffff800031ffe80
> fffffa800dd25000 fffffa800d2f3050 fffffa800d2f3118 : > ataport!IdePortCompletionDpc+0x1a8 > fffff80000ba2f00 fffff80003090165 : 0000000000000000
> fffffa800e7a3b60 0000000000000000 fffff88001108f5c : > nt!KiRetireDpcList+0x1bc > fffff80000ba2fb0 fffff8000308ff7c : fffffa800d2d8d80
> fffff96000096788 0000000025010101 fffff8800287a2a0 : > nt!KxRetireDpcList+0x5 > fffff8800287a1e0 fffff800030d9453 : fffff80003089063
> fffff800030890cf fffffa800e7a3b60 fffff8800287a2a0 : > nt!KiDispatchInterruptContinue > fffff8800287a210 fffff800030890cf : fffffa800e7a3b60
> fffff8800287a2a0 000000000185000f 00000000003085b0 : > nt!KiDpcInterruptBypass+0x13 > fffff8800287a220 000007fefbe71c61 : 000000000015f0a8
> 000000000033f750 000000000015f030 000007fefbd8560f : > nt!KiChainedDispatch+0x19f > 000000000015efe0 000007fefbe78ca9 : 0000000000320980
> 0000000000000000 0000800200000038 0000000000320a20 : > DUser!DuVisual::GetLogRect+0x296 > 000000000015f020 000007fefbe78dab : 0000000000000000
> 0000000000320980 0000000000000000 0000000000320c00 : > DUser!DuVisual::xrDrawTrivial+0x31 > 000000000015f080 000007fefbe78c5d : 0000000000000000
> 0000000000000000 0000000000000000 0000000000000000 : > DUser!DuVisual::xrDrawTrivial+0x151 > 000000000015f0e0 000007fefbe79703 : 0000000000000000
> 0000000000000000 0000000000000000 0000000000000000 : > DUser!DuVisual::xrDrawFull+0x929 > 000000000015f290 000007fefbe790d0 : 0000000000000000
> 0000000000000000 0000000000000001 0000000000000000 : > DUser!DuVisual::xrDrawFull+0x97d > 000000000015f440 000007fefbe78ff7 : 0000000000000000
> 0000000014010099 0000000000000000 0000000000000000 : > DUser!DuVisual::xrDrawStart+0x58 > 000000000015f470 000007fefbe78aa7 : 0000000000000001
> 000000000033f090 0000000014010099 000004b000000640 : > DUser!DuRootGadget::xrDrawTree+0x51c > 000000000015f650 000007fefbe71859 : 0000000000000000
> 0000000000000000 000004b000000000 0000000000000000 : > DUser!HWndContainer::xdHandleMessage+0x2b4 > 000000000015f950 00000000777f8971 : 0000000000000000
> 0000000000000000 0000000000000001 000007fefbe71785 : > DUser!ExtraInfoWndProc+0x8b > 000000000015f9b0 00000000777f72cb : 0000000000000000
> 000007fefbe717e4 0000000000000000 0000000000000000 : > USER32!UserCallWinProcCheckWow+0x163 > 000000000015fa70 00000000777f6829 : 0000000000000000
> 00000000777f919b 0000000000000000 0000000000000001 : > USER32!DispatchClientMessage+0xc3 > 000000000015fad0 0000000077931225 : 000000000000000f
> 0000000000000000 0000000000000000 0000032000006528 : USER32!_fnDWORD+0x2d > 000000000015fb30 00000000777f6e5a : 00000000777f6e6c
> 00000000000004ff 0000000000000000 0000000000000000 : > ntdll!KiUserCallbackDispatcherContinue > 000000000015fbb8 00000000777f6e6c : 00000000000004ff
> 0000000000000000 0000000000000000 0000000000000001 : > USER32!ZwUserDispatchMessage+0xa > 000000000015fbc0 000007fefc7b120b : 0000000000000000
> 0000000000000000 000007fefbe717e4 0000000000307320 : > USER32!DispatchMessageWorker+0x55b > 000000000015fc40 000007fefc7bb0fc : 0000000000000000
> 0000000000000001 0000000000000000 0000000000000000 : > authui!CLogonFrame::DoModal+0x13d > 000000000015fcc0 000007fefc7bb27f : 00000000002f31b0
> 00000000002e0df0 00000000002db010 00000000002528e6 : > authui!CLogonUI_CreateThenDoModalThenDestroy+0x299 > 000000000015fd20 00000000ff6354ff : 00000000002d22f0
> 00000000002d22f0 0000000000000000 000000000000000b : > authui!CLogonUI::DoModal+0x73 > 000000000015fd50 00000000ff635b06 : 0000000000000000
> 0000000000000000 0000000000000000 00000000ff631178 : > LogonUI!wWinMain+0xfb > 000000000015fdb0 00000000776d652d : 0000000000000000
> 0000000000000000 0000000000000000 0000000000000000 : > LogonUI!ParseCommandLineToStringArrayLocalAlloc+0x33a > 000000000015fe70 000000007790c521 : 0000000000000000
> 0000000000000000 0000000000000000 0000000000000000 : > kernel32!BaseThreadInitThunk+0xd > 000000000015fea0 0000000000000000 : 0000000000000000
> 0000000000000000 0000000000000000 00000000`00000000 :
> ntdll!RtlUserThreadStart+0x1d
>
>
> STACK_COMMAND: .trap 0xfffff80000ba1d00 ; kb
>
> CHKIMG_EXTENSION: !chkimg -lo 50 -d !nt
> fffff80003090203 - nt!SwapContext_PatchXSave+2
> [01:21]
> fffff800030902e4 - nt!SwapContext_PatchXRstor+2 (+0xe1)
> [09:29]
> fffff800030904a3 - nt!EnlightenedSwapContext_PatchXSave+2 (+0x1bf)
> [01:21]
> fffff80003090586 - nt!EnlightenedSwapContext_PatchXRstor+2 (+0xe3)
> [09:29]
> 4 errors : !nt (fffff80003090203-fffff80003090586)
>
> MODULE_NAME: memory_corruption
>
> IMAGE_NAME: memory_corruption
>
> FOLLOWUP_NAME: memory_corruption
>
> DEBUG_FLR_IMAGE_TIMESTAMP: 0
>
> MEMORY_CORRUPTOR: ONE_BIT_LARGE
>
> FAILURE_BUCKET_ID: X64_MEMORY_CORRUPTION_ONE_BIT_LARGE
>
> BUCKET_ID: X64_MEMORY_CORRUPTION_ONE_BIT_LARGE
>
> Followup: memory_corruption
> ---------
>
> – mkj
>
> //
> // Michael K. Jones
> // Stone Hill Consulting, LLC
> // http://www.stonehill.com
> //
>
> —
> NTDEV is sponsored by OSR
>
> Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev
>
> OSR is HIRING!! See http://www.osr.com/careers
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
>

–
– mkj

//
// Michael K. Jones
// Stone Hill Consulting, LLC
// http://www.stonehill.com
//

—
NTDEV is sponsored by OSR

Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev

OSR is HIRING!! See http://www.osr.com/careers

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

OSR_Community_User · July 18, 2014, 1:46am

One thing I learned when I was doing debugging was that the real-time
parts couldn’t be delayed. In one pattern I used a lot, I recorded
ISR-related events in a circular buffer. I then had ways to get at that
buffer, such as the equivalent of
DeviceIoControl(…MY_IOCTL_RETRIEVE_RT_BUFFER, …); in another driver I
made sure that I recorded the pointer to the buffer so I could find it in
the crash dump. In most cases, I only needed to record the event type and
an 8-bit parameter; in one, I recorded a timestamp as well because I
needed to know the interarrival and service times. In one case, I had a
macro that did

CLI; NOP; STI;

and if I wanted to set a breakpoint, I put it on the NOP, so I could stop
the program and not have interrupts continue to come in (yes, it screwed
up realtime response time, but all that meant was that it couldn’t shut
off sound at the right time. But that’s what volume controls are for).

Debugging realtime provides its own set of challenges, but there was a
time in my life when I enjoyed those challenges. Now, I try to avoid it.
joe

Michael Jones wrote:
> I suspect this is happening because the ISR in this driver spews a lot
> of messages, and the IRQ is shared with lots of other devices, so this
> driver’s ISR gets called a lot, only to discover the interrupt is not
> from it’s device.

I keep having to re-learn the lesson of how large the performance
penalty of DbgPrint is, especially because I work in real-time systems
like audio and video. As a rule, I almost never do any DbgPrints in the
ISR. I don’t mind so much in a DPC.

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

NTDEV is sponsored by OSR

Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev

OSR is HIRING!! See http://www.osr.com/careers

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

OSR_Community_User · July 18, 2014, 2:22am

You nominally have a 10usec budget for the ISR. Formatting a string will
stress this limit; outputting it blows your budget to pieces. See my
comment about realtime debugging. It is not for the faint of heart, and
has serious challenges. Putting the buffer on the stack is critical.
While you cannot have two threads executing the same ISR at the same time
from a single device, you CAN have two threads executing the same ISR for
different devices. But putting the buffer on the stack is not the issue
(I’m assuming it is a small buffer). The formatting time could be a
problem, but the output time is DEFINITELY hazardous to your realtime
health. What is it you are displaying, and would my circular-buffer
solution handle it? Note that you can either retrieve the buffer
explicitly or print it out in the DPC (note that there are some
fascinating problems in how to synchronize the ISRs for two or more
devices, and I’ll leave it up to those more expert than I to suggest how
to handle this. So you may need to put the buffer (or a pointer to the
buffer which is dynamically allocated) in the device extension). Don’t do
anything lengthy in the ISR.
joe

what you do in the isr? i advice you finish it quickly and leave data
process in dpc. i’m not sure what the dpc timeout is caused by, but check
your code and make isr as simple as possible.

===================
best regards!
zhang pei

Michael Jones ç¼–å†™ï¼š
>
> Thanks for your response!
>
> The buffer used to format the trace string is on the stack, so not paged
> memory. The code uses RtlStringCbVPrintfA (and checks the return
> value), so not a problem with buffer overflow happening.
>
> I’m not too keen on the fact that the buffer is on the stack; however, I
> don’t believe it’s overflowing the stack. I’ve had that problem in the
> past (with other drivers), and IIRC it’s a pretty explicit bug check,
> which I’m not seeing in this case. Isn’t there a guard page after
> (well, before) the stack?
>
> I will probably change that buffer to not occupy stack space; however,
> it’s not a trivial change since I believe it was originally written that
> way in order to avoid traces from multiple threads stepping on each
> other. So I’m trying to avoid making that sort of change until I get a
> better handle on the bug I’m currently chasing.
>
> Cheers,
>
> --mkj
>
>
> On 7/17/2014 6:20 PM, zhang pei wrote:
>> you are writting log from the isr. check if you are referencing some
>> paged content and if you are writting too much content which over the
>> buffer size.
>>
>>
>>
>> ===================
>> best regards!
>> zhang pei
>>
>>
>> Michael Jones ç¼–å†™ï¼š
>>
>> I’m chasing a problem for a client where a driver for one of their cards
>> hangs when the system starts. I am unable to reproduce it with my
>> hardware (naturally). However, I do get this when start my hardware
>> (which is set up for debugging):
>>
>> Assertion: DPC watchdog timeout
>> This is NOT a break in update time
>> This is most likely a BUG in an ISR
>> Perform a stack trace to find the culprit
>> The period will be doubled on continuation
>> Use gh to continue!!
>>
>> nt! ?? ::FNODOBFM::string'+0x4f3a: >> fffff800030e4b75 cd2c int 2Ch
>>
>> I suspect this is happening because the ISR in this driver spews a lot
>> of messages, and the IRQ is shared with lots of other devices, so this
>> driver’s ISR gets called a lot, only to discover the interrupt is not
>> from it’s device.
>>
>> In any event, I did a “gn”, just to see what the BSOD would look like
>> without Windbg hooked up (in case this is what the client is seeing).
>> The analyze -v is below.
>>
>> I get that the bugcheck is INTERRUPT_EXCEPTION_NOT_HANDLED (since I did
>> a “gn” instead of a “gh”). However, I don’t understand the stuff about
>> CODE_CURRUPTION, and the memory corruption stuff at the end of the
>> analyze. Can anyone enlighten me?
>>
>> TIA, --mkj
>>
>>
>>
>> 0: kd> !analyze -v
>>****************************************************************************
>> *
>> *
>> * Bugcheck Analysis
>> *
>> *
>> *
>> *******************************************************************************
>>
>> INTERRUPT_EXCEPTION_NOT_HANDLED (3d)
>> Arguments:
>> Arg1: fffff80000ba0600
>> Arg2: 0000000000000000
>> Arg3: 0000000000000000
>> Arg4: fffff800030e4b75
>>
>> Debugging Details:
>> ------------------
>>
>>
>> CONTEXT: fffff80000ba0600 – (.cxr 0xfffff80000ba0600)
>> rax=0000001cbc843b72 rbx=fffff800031ffe80 rcx=0000000000000002
>> rdx=0000000000000000 rsi=fffffa800e7a3b60 rdi=0000000000000001
>> rip=fffff800030e4b75 rsp=fffff80000ba0fe0 rbp=0000000000000001
>> r8=0000000000000000 r9=0000000000000000 r10=0000000000000000
>> r11=fffff80000ba10c0 r12=0000000000000000 r13=000000000000000a
>> r14=0000000000000004 r15=0000000000000001
>> iopl=0 nv up ei pl zr na po nc
>> cs=0010 ss=0018 ds=002b es=002b fs=0053 gs=002b
>> efl=00000246
>> nt! ?? ::FNODOBFM::string'+0x4f3a: >> fffff800030e4b75 cd2c int 2Ch
>> Resetting default scope
>>
>> DEFAULT_BUCKET_ID: CODE_CORRUPTION
>>
>> BUGCHECK_STR: 0x3D
>>
>> PROCESS_NAME: LogonUI.exe
>>
>> CURRENT_IRQL: d
>>
>> EXCEPTION_RECORD: fffff80000ba1c58 – (.exr 0xfffff80000ba1c58)
>> ExceptionAddress: fffff800030854b5 (nt!DebugPrint+0x0000000000000015)
>> ExceptionCode: 80000003 (Break instruction exception)
>> ExceptionFlags: 00000000
>> NumberParameters: 1
>> Parameter[0]: 0000000000000001
>>
>> TRAP_FRAME: fffff80000ba1d00 – (.trap 0xfffff80000ba1d00)
>> NOTE: The trap frame does not contain all registers.
>> Some register values may be zeroed or incorrect.
>> rax=0000000000000001 rbx=0000000000000000 rcx=fffff80000ba1f00
>> rdx=000000000000002f rsi=0000000000000000 rdi=0000000000000000
>> rip=fffff800030854b5 rsp=fffff80000ba1e98 rbp=fffff80000ba27b0
>> r8=0000000000000065 r9=0000000000000003 r10=0000000000000000
>> r11=fffff80000ba1db0 r12=0000000000000000 r13=0000000000000000
>> r14=0000000000000000 r15=0000000000000000
>> iopl=0 nv up ei ng nz ac po cy
>> nt!DebugPrint+0x15:
>> fffff800030854b5 c3 ret >> Resetting default scope >> >> LAST_CONTROL_TRANSFER: from fffff80003097eb7 to fffff800030e4b75 >> >> STACK_TEXT: >> fffff80000ba1e98 fffff800030cd675 : 0000000000000000
>> 0000000000000000 0000000000000000 fffff80000ba27b0 : >> nt!DebugPrint+0x15 >> fffff80000ba1ea0 fffff8000313cd0c : 0000000000000000
>> fffff88002fc6e00 fffff80000ba2588 46464646463d2073 : nt! ?? >> ::FNODOBFM::string’+0xc642
>> fffff80000ba2150 fffff88002fbf40b : fffff88002fc6d90 >> fffff80000ba21c0 0000000000000000 00000000fffffffe : nt!DbgPrint+0x3c
>> fffff80000ba2190 fffff88002fbfbda : fffffa8000000005 >> fffff88000000040 fffff88002fc6e00 0000000000000000 :
>> Acrmgpci!DebugPrint+0xcb
>> [c:\clients\xembedded\src\trunk\acrmgpci\driver\driver.c @ 1630]
>> fffff80000ba2570 fffff88002fbfd65 : 00007fff00000000 >> 0000ff1e00000022 fffffa800dbd4af0 fffffa800dbd4af0 :
>> Acrmgpci!LogIsrCode+0x7a
>> [c:\clients\xembedded\src\trunk\acrmgpci\driver\registry.c @ 665]
>> fffff80000ba25d0 fffff88002fbde70 : fffffa800d6a2a80 >> fffffa800d550120 fffffa800daca020 0000000000000000 :
>> Acrmgpci!RunISRCode+0xd5
>> [c:\clients\xembedded\src\trunk\acrmgpci\driver\registry.c @ 714]
>> fffff80000ba26a0 fffff80003089279 : fffffa800d2d8d80 >> fffffa800d6a2a80 fffffa800d2d8d80 0000000000000000 :
>> Acrmgpci!HandleInterrupt+0x30
>> [c:\clients\xembedded\src\trunk\acrmgpci\driver\driver.c @ 441]
>> fffff80000ba26e0 fffff80003089058 : 000000000000001b >> fffff880011289e5 fffff80000ba28a0 fffff8000300d000 :
>> nt!KiScanInterruptObjectList+0x69
>> fffff80000ba2730 fffff800036066f9 : fffff88000fc6a2c >> 0000000000001000 fffffa800d443ac0 fffffa800d44fa20 :
>> nt!KiChainedDispatch+0x128
>> fffff80000ba28c8 fffff88000fc6a2c : 0000000000001000 >> fffffa800d443ac0 fffffa800d44fa20 fffffa800eadbc60 :
>> hal!KeQueryPerformanceCounter+0x5
>> fffff80000ba28d0 fffff88000fd9c7f : fffffa800d440b20 >> 0000000000000000 fffffa800d4409d0 fffffa800eadbc60 :
>> partmgr!PmWmiCounterIoComplete+0x2c
>> fffff80000ba2900 fffff80003090a91 : fffffa800eadbe0b >> fffffa800d4409d0 fffffa800eadbc60 fffffa800eadbc60 : volmgr! ??
>> ::FNODOBFM::string'+0x2cc >> fffff80000ba2940 fffff88001851bce : 000000000000008b
>> 0000000000000001 fffffa800d2e57d0 0000000000000000 : >> nt!IopfCompleteRequest+0x3b1 >> fffff80000ba2a20 fffff80003090a91 : 0000000000000000
>> 0000000000000000 0000000000000000 0000000000000000 : >> CLASSPNP!TransferPktComplete+0x1ce >> fffff80000ba2aa0 fffff8800110641a : fffffa800d2d8540
>> 0000000000000001 fffffa800db24b80 0000000000000000 : >> nt!IopfCompleteRequest+0x3b1 >> fffff80000ba2b80 fffff88001106242 : fffffa800db24b80
>> ffff008004414bda fffffa800d2d8d01 0000000000000000 : >> ataport!IdeCompleteScsiIrp+0x62 >> fffff80000ba2bb0 fffff88001100e32 : 0000000000000002
>> 0000000000000000 0000000000000004 0000ff1e00000004 : >> ataport!IdeCommonCrbCompletion+0x5a >> fffff80000ba2be0 fffff88001109805 : fffffa800d2f31a0
>> fffffa800db24b80 0000000000000000 0000000000000000 : >> ataport!IdeTranslateCompletedRequest+0x236 >> fffff80000ba2d10 fffff88001109104 : fffffa800d2f31a0
>> 0000000000000000 fffffa800d2f31a0 0000000000000000 : >> ataport!IdeProcessCompletedRequests+0x4d5 >> fffff80000ba2e40 fffff80003098b1c : fffff800031ffe80
>> fffffa800dd25000 fffffa800d2f3050 fffffa800d2f3118 : >> ataport!IdePortCompletionDpc+0x1a8 >> fffff80000ba2f00 fffff80003090165 : 0000000000000000
>> fffffa800e7a3b60 0000000000000000 fffff88001108f5c : >> nt!KiRetireDpcList+0x1bc >> fffff80000ba2fb0 fffff8000308ff7c : fffffa800d2d8d80
>> fffff96000096788 0000000025010101 fffff8800287a2a0 : >> nt!KxRetireDpcList+0x5 >> fffff8800287a1e0 fffff800030d9453 : fffff80003089063
>> fffff800030890cf fffffa800e7a3b60 fffff8800287a2a0 : >> nt!KiDispatchInterruptContinue >> fffff8800287a210 fffff800030890cf : fffffa800e7a3b60
>> fffff8800287a2a0 000000000185000f 00000000003085b0 : >> nt!KiDpcInterruptBypass+0x13 >> fffff8800287a220 000007fefbe71c61 : 000000000015f0a8
>> 000000000033f750 000000000015f030 000007fefbd8560f : >> nt!KiChainedDispatch+0x19f >> 000000000015efe0 000007fefbe78ca9 : 0000000000320980
>> 0000000000000000 0000800200000038 0000000000320a20 : >> DUser!DuVisual::GetLogRect+0x296 >> 000000000015f020 000007fefbe78dab : 0000000000000000
>> 0000000000320980 0000000000000000 0000000000320c00 : >> DUser!DuVisual::xrDrawTrivial+0x31 >> 000000000015f080 000007fefbe78c5d : 0000000000000000
>> 0000000000000000 0000000000000000 0000000000000000 : >> DUser!DuVisual::xrDrawTrivial+0x151 >> 000000000015f0e0 000007fefbe79703 : 0000000000000000
>> 0000000000000000 0000000000000000 0000000000000000 : >> DUser!DuVisual::xrDrawFull+0x929 >> 000000000015f290 000007fefbe790d0 : 0000000000000000
>> 0000000000000000 0000000000000001 0000000000000000 : >> DUser!DuVisual::xrDrawFull+0x97d >> 000000000015f440 000007fefbe78ff7 : 0000000000000000
>> 0000000014010099 0000000000000000 0000000000000000 : >> DUser!DuVisual::xrDrawStart+0x58 >> 000000000015f470 000007fefbe78aa7 : 0000000000000001
>> 000000000033f090 0000000014010099 000004b000000640 : >> DUser!DuRootGadget::xrDrawTree+0x51c >> 000000000015f650 000007fefbe71859 : 0000000000000000
>> 0000000000000000 000004b000000000 0000000000000000 : >> DUser!HWndContainer::xdHandleMessage+0x2b4 >> 000000000015f950 00000000777f8971 : 0000000000000000
>> 0000000000000000 0000000000000001 000007fefbe71785 : >> DUser!ExtraInfoWndProc+0x8b >> 000000000015f9b0 00000000777f72cb : 0000000000000000
>> 000007fefbe717e4 0000000000000000 0000000000000000 : >> USER32!UserCallWinProcCheckWow+0x163 >> 000000000015fa70 00000000777f6829 : 0000000000000000
>> 00000000777f919b 0000000000000000 0000000000000001 : >> USER32!DispatchClientMessage+0xc3 >> 000000000015fad0 0000000077931225 : 000000000000000f
>> 0000000000000000 0000000000000000 0000032000006528 : >> USER32!_fnDWORD+0x2d >> 000000000015fb30 00000000777f6e5a : 00000000777f6e6c
>> 00000000000004ff 0000000000000000 0000000000000000 : >> ntdll!KiUserCallbackDispatcherContinue >> 000000000015fbb8 00000000777f6e6c : 00000000000004ff
>> 0000000000000000 0000000000000000 0000000000000001 : >> USER32!ZwUserDispatchMessage+0xa >> 000000000015fbc0 000007fefc7b120b : 0000000000000000
>> 0000000000000000 000007fefbe717e4 0000000000307320 : >> USER32!DispatchMessageWorker+0x55b >> 000000000015fc40 000007fefc7bb0fc : 0000000000000000
>> 0000000000000001 0000000000000000 0000000000000000 : >> authui!CLogonFrame::DoModal+0x13d >> 000000000015fcc0 000007fefc7bb27f : 00000000002f31b0
>> 00000000002e0df0 00000000002db010 00000000002528e6 : >> authui!CLogonUI_CreateThenDoModalThenDestroy+0x299 >> 000000000015fd20 00000000ff6354ff : 00000000002d22f0
>> 00000000002d22f0 0000000000000000 000000000000000b : >> authui!CLogonUI::DoModal+0x73 >> 000000000015fd50 00000000ff635b06 : 0000000000000000
>> 0000000000000000 0000000000000000 00000000ff631178 : >> LogonUI!wWinMain+0xfb >> 000000000015fdb0 00000000776d652d : 0000000000000000
>> 0000000000000000 0000000000000000 0000000000000000 : >> LogonUI!ParseCommandLineToStringArrayLocalAlloc+0x33a >> 000000000015fe70 000000007790c521 : 0000000000000000
>> 0000000000000000 0000000000000000 0000000000000000 : >> kernel32!BaseThreadInitThunk+0xd >> 000000000015fea0 0000000000000000 : 0000000000000000
>> 0000000000000000 0000000000000000 00000000`00000000 :
>> ntdll!RtlUserThreadStart+0x1d
>>
>>
>> STACK_COMMAND: .trap 0xfffff80000ba1d00 ; kb
>>
>> CHKIMG_EXTENSION: !chkimg -lo 50 -d !nt
>> fffff80003090203 - nt!SwapContext_PatchXSave+2
>> [01:21]
>> fffff800030902e4 - nt!SwapContext_PatchXRstor+2 (+0xe1)
>> [09:29]
>> fffff800030904a3 - nt!EnlightenedSwapContext_PatchXSave+2 (+0x1bf)
>> [01:21]
>> fffff80003090586 - nt!EnlightenedSwapContext_PatchXRstor+2 (+0xe3)
>> [09:29]
>> 4 errors : !nt (fffff80003090203-fffff80003090586)
>>
>> MODULE_NAME: memory_corruption
>>
>> IMAGE_NAME: memory_corruption
>>
>> FOLLOWUP_NAME: memory_corruption
>>
>> DEBUG_FLR_IMAGE_TIMESTAMP: 0
>>
>> MEMORY_CORRUPTOR: ONE_BIT_LARGE
>>
>> FAILURE_BUCKET_ID: X64_MEMORY_CORRUPTION_ONE_BIT_LARGE
>>
>> BUCKET_ID: X64_MEMORY_CORRUPTION_ONE_BIT_LARGE
>>
>> Followup: memory_corruption
>> ---------
>>
>> – mkj
>>
>> //
>> // Michael K. Jones
>> // Stone Hill Consulting, LLC
>> // http://www.stonehill.com
>> //
>>
>> —
>> NTDEV is sponsored by OSR
>>
>> Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev
>>
>> OSR is HIRING!! See http://www.osr.com/careers
>>
>> For our schedule of WDF, WDM, debugging and other seminars visit:
>> http://www.osr.com/seminars
>>
>> To unsubscribe, visit the List Server section of OSR Online at
>> http://www.osronline.com/page.cfm?name=ListServer
>>
>
> –
> – mkj
>
> //
> // Michael K. Jones
> // Stone Hill Consulting, LLC
> // http://www.stonehill.com
> //
>
> —
> NTDEV is sponsored by OSR
>
> Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev
>
> OSR is HIRING!! See http://www.osr.com/careers
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>
> —
> NTDEV is sponsored by OSR
>
> Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev
>
> OSR is HIRING!! See http://www.osr.com/careers
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>

Scott_Noone_OSR · July 18, 2014, 12:27pm

CODE_CORRUPTION is just the Online Crash Analysis bucket ID, so it’s just a
guess that !analyze makes. An unhandled exception from the interrupt
dispatching code would be highly unusual, so I suspect it’s a reasonable
guess in most of these cases. Clearly in yours though it’s really unrelated.

RtlStringCbVPrintfA in an ISR would be a Really Bad Idea. Note that the
documentation specifies an IRQL restriction of PASSIVE_LEVEL on that API.

-scott
OSR
@OSRdrivers

“Michael Jones” wrote in message news:xxxxx@ntdev…

Thanks for your response!

The buffer used to format the trace string is on the stack, so not paged
memory. The code uses RtlStringCbVPrintfA (and checks the return
value), so not a problem with buffer overflow happening.

I’m not too keen on the fact that the buffer is on the stack; however, I
don’t believe it’s overflowing the stack. I’ve had that problem in the
past (with other drivers), and IIRC it’s a pretty explicit bug check,
which I’m not seeing in this case. Isn’t there a guard page after
(well, before) the stack?

I will probably change that buffer to not occupy stack space; however,
it’s not a trivial change since I believe it was originally written that
way in order to avoid traces from multiple threads stepping on each
other. So I’m trying to avoid making that sort of change until I get a
better handle on the bug I’m currently chasing.

Cheers,

–mkj

On 7/17/2014 6:20 PM, zhang pei wrote:

you are writting log from the isr. check if you are referencing some paged
content and if you are writting too much content which over the buffer
size.

===================
best regards!
zhang pei

Michael Jones ç¼–å†™ï¼š
>
> I’m chasing a problem for a client where a driver for one of their cards
> hangs when the system starts. I am unable to reproduce it with my
> hardware (naturally). However, I do get this when start my hardware
> (which is set up for debugging):
>
> Assertion: DPC watchdog timeout
> This is NOT a break in update time
> This is most likely a BUG in an ISR
> Perform a stack trace to find the culprit
> The period will be doubled on continuation
> Use gh to continue!!
>
> nt! ?? ::FNODOBFM::string'+0x4f3a: > fffff800030e4b75 cd2c int 2Ch
>
> I suspect this is happening because the ISR in this driver spews a lot
> of messages, and the IRQ is shared with lots of other devices, so this
> driver’s ISR gets called a lot, only to discover the interrupt is not
> from it’s device.
>
> In any event, I did a “gn”, just to see what the BSOD would look like
> without Windbg hooked up (in case this is what the client is seeing).
> The analyze -v is below.
>
> I get that the bugcheck is INTERRUPT_EXCEPTION_NOT_HANDLED (since I did
> a “gn” instead of a “gh”). However, I don’t understand the stuff about
> CODE_CURRUPTION, and the memory corruption stuff at the end of the
> analyze. Can anyone enlighten me?
>
> TIA, --mkj
>
>
>
> 0: kd> !analyze -v
>****************************************************************************
> *
> *
> * Bugcheck Analysis
> *
> *
> *
> *******************************************************************************
>
> INTERRUPT_EXCEPTION_NOT_HANDLED (3d)
> Arguments:
> Arg1: fffff80000ba0600
> Arg2: 0000000000000000
> Arg3: 0000000000000000
> Arg4: fffff800030e4b75
>
> Debugging Details:
> ------------------
>
>
> CONTEXT: fffff80000ba0600 – (.cxr 0xfffff80000ba0600)
> rax=0000001cbc843b72 rbx=fffff800031ffe80 rcx=0000000000000002
> rdx=0000000000000000 rsi=fffffa800e7a3b60 rdi=0000000000000001
> rip=fffff800030e4b75 rsp=fffff80000ba0fe0 rbp=0000000000000001
> r8=0000000000000000 r9=0000000000000000 r10=0000000000000000
> r11=fffff80000ba10c0 r12=0000000000000000 r13=000000000000000a
> r14=0000000000000004 r15=0000000000000001
> iopl=0 nv up ei pl zr na po nc
> cs=0010 ss=0018 ds=002b es=002b fs=0053 gs=002b
> efl=00000246
> nt! ?? ::FNODOBFM::string'+0x4f3a: > fffff800030e4b75 cd2c int 2Ch
> Resetting default scope
>
> DEFAULT_BUCKET_ID: CODE_CORRUPTION
>
> BUGCHECK_STR: 0x3D
>
> PROCESS_NAME: LogonUI.exe
>
> CURRENT_IRQL: d
>
> EXCEPTION_RECORD: fffff80000ba1c58 – (.exr 0xfffff80000ba1c58)
> ExceptionAddress: fffff800030854b5 (nt!DebugPrint+0x0000000000000015)
> ExceptionCode: 80000003 (Break instruction exception)
> ExceptionFlags: 00000000
> NumberParameters: 1
> Parameter[0]: 0000000000000001
>
> TRAP_FRAME: fffff80000ba1d00 – (.trap 0xfffff80000ba1d00)
> NOTE: The trap frame does not contain all registers.
> Some register values may be zeroed or incorrect.
> rax=0000000000000001 rbx=0000000000000000 rcx=fffff80000ba1f00
> rdx=000000000000002f rsi=0000000000000000 rdi=0000000000000000
> rip=fffff800030854b5 rsp=fffff80000ba1e98 rbp=fffff80000ba27b0
> r8=0000000000000065 r9=0000000000000003 r10=0000000000000000
> r11=fffff80000ba1db0 r12=0000000000000000 r13=0000000000000000
> r14=0000000000000000 r15=0000000000000000
> iopl=0 nv up ei ng nz ac po cy
> nt!DebugPrint+0x15:
> fffff800030854b5 c3 ret > Resetting default scope > > LAST_CONTROL_TRANSFER: from fffff80003097eb7 to fffff800030e4b75 > > STACK_TEXT: > fffff80000ba1e98 fffff800030cd675 : 0000000000000000
> 0000000000000000 0000000000000000 fffff80000ba27b0 : nt!DebugPrint+0x15 > fffff80000ba1ea0 fffff8000313cd0c : 0000000000000000
> fffff88002fc6e00 fffff80000ba2588 46464646463d2073 : nt! ?? > ::FNODOBFM::string’+0xc642
> fffff80000ba2150 fffff88002fbf40b : fffff88002fc6d90 > fffff80000ba21c0 0000000000000000 00000000fffffffe : nt!DbgPrint+0x3c
> fffff80000ba2190 fffff88002fbfbda : fffffa8000000005 > fffff88000000040 fffff88002fc6e00 0000000000000000 :
> Acrmgpci!DebugPrint+0xcb
> [c:\clients\xembedded\src\trunk\acrmgpci\driver\driver.c @ 1630]
> fffff80000ba2570 fffff88002fbfd65 : 00007fff00000000 > 0000ff1e00000022 fffffa800dbd4af0 fffffa800dbd4af0 :
> Acrmgpci!LogIsrCode+0x7a
> [c:\clients\xembedded\src\trunk\acrmgpci\driver\registry.c @ 665]
> fffff80000ba25d0 fffff88002fbde70 : fffffa800d6a2a80 > fffffa800d550120 fffffa800daca020 0000000000000000 :
> Acrmgpci!RunISRCode+0xd5
> [c:\clients\xembedded\src\trunk\acrmgpci\driver\registry.c @ 714]
> fffff80000ba26a0 fffff80003089279 : fffffa800d2d8d80 > fffffa800d6a2a80 fffffa800d2d8d80 0000000000000000 :
> Acrmgpci!HandleInterrupt+0x30
> [c:\clients\xembedded\src\trunk\acrmgpci\driver\driver.c @ 441]
> fffff80000ba26e0 fffff80003089058 : 000000000000001b > fffff880011289e5 fffff80000ba28a0 fffff8000300d000 :
> nt!KiScanInterruptObjectList+0x69
> fffff80000ba2730 fffff800036066f9 : fffff88000fc6a2c > 0000000000001000 fffffa800d443ac0 fffffa800d44fa20 :
> nt!KiChainedDispatch+0x128
> fffff80000ba28c8 fffff88000fc6a2c : 0000000000001000 > fffffa800d443ac0 fffffa800d44fa20 fffffa800eadbc60 :
> hal!KeQueryPerformanceCounter+0x5
> fffff80000ba28d0 fffff88000fd9c7f : fffffa800d440b20 > 0000000000000000 fffffa800d4409d0 fffffa800eadbc60 :
> partmgr!PmWmiCounterIoComplete+0x2c
> fffff80000ba2900 fffff80003090a91 : fffffa800eadbe0b > fffffa800d4409d0 fffffa800eadbc60 fffffa800eadbc60 : volmgr! ??
> ::FNODOBFM::string'+0x2cc > fffff80000ba2940 fffff88001851bce : 000000000000008b
> 0000000000000001 fffffa800d2e57d0 0000000000000000 : > nt!IopfCompleteRequest+0x3b1 > fffff80000ba2a20 fffff80003090a91 : 0000000000000000
> 0000000000000000 0000000000000000 0000000000000000 : > CLASSPNP!TransferPktComplete+0x1ce > fffff80000ba2aa0 fffff8800110641a : fffffa800d2d8540
> 0000000000000001 fffffa800db24b80 0000000000000000 : > nt!IopfCompleteRequest+0x3b1 > fffff80000ba2b80 fffff88001106242 : fffffa800db24b80
> ffff008004414bda fffffa800d2d8d01 0000000000000000 : > ataport!IdeCompleteScsiIrp+0x62 > fffff80000ba2bb0 fffff88001100e32 : 0000000000000002
> 0000000000000000 0000000000000004 0000ff1e00000004 : > ataport!IdeCommonCrbCompletion+0x5a > fffff80000ba2be0 fffff88001109805 : fffffa800d2f31a0
> fffffa800db24b80 0000000000000000 0000000000000000 : > ataport!IdeTranslateCompletedRequest+0x236 > fffff80000ba2d10 fffff88001109104 : fffffa800d2f31a0
> 0000000000000000 fffffa800d2f31a0 0000000000000000 : > ataport!IdeProcessCompletedRequests+0x4d5 > fffff80000ba2e40 fffff80003098b1c : fffff800031ffe80
> fffffa800dd25000 fffffa800d2f3050 fffffa800d2f3118 : > ataport!IdePortCompletionDpc+0x1a8 > fffff80000ba2f00 fffff80003090165 : 0000000000000000
> fffffa800e7a3b60 0000000000000000 fffff88001108f5c : > nt!KiRetireDpcList+0x1bc > fffff80000ba2fb0 fffff8000308ff7c : fffffa800d2d8d80
> fffff96000096788 0000000025010101 fffff8800287a2a0 : > nt!KxRetireDpcList+0x5 > fffff8800287a1e0 fffff800030d9453 : fffff80003089063
> fffff800030890cf fffffa800e7a3b60 fffff8800287a2a0 : > nt!KiDispatchInterruptContinue > fffff8800287a210 fffff800030890cf : fffffa800e7a3b60
> fffff8800287a2a0 000000000185000f 00000000003085b0 : > nt!KiDpcInterruptBypass+0x13 > fffff8800287a220 000007fefbe71c61 : 000000000015f0a8
> 000000000033f750 000000000015f030 000007fefbd8560f : > nt!KiChainedDispatch+0x19f > 000000000015efe0 000007fefbe78ca9 : 0000000000320980
> 0000000000000000 0000800200000038 0000000000320a20 : > DUser!DuVisual::GetLogRect+0x296 > 000000000015f020 000007fefbe78dab : 0000000000000000
> 0000000000320980 0000000000000000 0000000000320c00 : > DUser!DuVisual::xrDrawTrivial+0x31 > 000000000015f080 000007fefbe78c5d : 0000000000000000
> 0000000000000000 0000000000000000 0000000000000000 : > DUser!DuVisual::xrDrawTrivial+0x151 > 000000000015f0e0 000007fefbe79703 : 0000000000000000
> 0000000000000000 0000000000000000 0000000000000000 : > DUser!DuVisual::xrDrawFull+0x929 > 000000000015f290 000007fefbe790d0 : 0000000000000000
> 0000000000000000 0000000000000001 0000000000000000 : > DUser!DuVisual::xrDrawFull+0x97d > 000000000015f440 000007fefbe78ff7 : 0000000000000000
> 0000000014010099 0000000000000000 0000000000000000 : > DUser!DuVisual::xrDrawStart+0x58 > 000000000015f470 000007fefbe78aa7 : 0000000000000001
> 000000000033f090 0000000014010099 000004b000000640 : > DUser!DuRootGadget::xrDrawTree+0x51c > 000000000015f650 000007fefbe71859 : 0000000000000000
> 0000000000000000 000004b000000000 0000000000000000 : > DUser!HWndContainer::xdHandleMessage+0x2b4 > 000000000015f950 00000000777f8971 : 0000000000000000
> 0000000000000000 0000000000000001 000007fefbe71785 : > DUser!ExtraInfoWndProc+0x8b > 000000000015f9b0 00000000777f72cb : 0000000000000000
> 000007fefbe717e4 0000000000000000 0000000000000000 : > USER32!UserCallWinProcCheckWow+0x163 > 000000000015fa70 00000000777f6829 : 0000000000000000
> 00000000777f919b 0000000000000000 0000000000000001 : > USER32!DispatchClientMessage+0xc3 > 000000000015fad0 0000000077931225 : 000000000000000f
> 0000000000000000 0000000000000000 0000032000006528 : > USER32!_fnDWORD+0x2d > 000000000015fb30 00000000777f6e5a : 00000000777f6e6c
> 00000000000004ff 0000000000000000 0000000000000000 : > ntdll!KiUserCallbackDispatcherContinue > 000000000015fbb8 00000000777f6e6c : 00000000000004ff
> 0000000000000000 0000000000000000 0000000000000001 : > USER32!ZwUserDispatchMessage+0xa > 000000000015fbc0 000007fefc7b120b : 0000000000000000
> 0000000000000000 000007fefbe717e4 0000000000307320 : > USER32!DispatchMessageWorker+0x55b > 000000000015fc40 000007fefc7bb0fc : 0000000000000000
> 0000000000000001 0000000000000000 0000000000000000 : > authui!CLogonFrame::DoModal+0x13d > 000000000015fcc0 000007fefc7bb27f : 00000000002f31b0
> 00000000002e0df0 00000000002db010 00000000002528e6 : > authui!CLogonUI_CreateThenDoModalThenDestroy+0x299 > 000000000015fd20 00000000ff6354ff : 00000000002d22f0
> 00000000002d22f0 0000000000000000 000000000000000b : > authui!CLogonUI::DoModal+0x73 > 000000000015fd50 00000000ff635b06 : 0000000000000000
> 0000000000000000 0000000000000000 00000000ff631178 : > LogonUI!wWinMain+0xfb > 000000000015fdb0 00000000776d652d : 0000000000000000
> 0000000000000000 0000000000000000 0000000000000000 : > LogonUI!ParseCommandLineToStringArrayLocalAlloc+0x33a > 000000000015fe70 000000007790c521 : 0000000000000000
> 0000000000000000 0000000000000000 0000000000000000 : > kernel32!BaseThreadInitThunk+0xd > 000000000015fea0 0000000000000000 : 0000000000000000
> 0000000000000000 0000000000000000 00000000`00000000 :
> ntdll!RtlUserThreadStart+0x1d
>
>
> STACK_COMMAND: .trap 0xfffff80000ba1d00 ; kb
>
> CHKIMG_EXTENSION: !chkimg -lo 50 -d !nt
> fffff80003090203 - nt!SwapContext_PatchXSave+2
> [01:21]
> fffff800030902e4 - nt!SwapContext_PatchXRstor+2 (+0xe1)
> [09:29]
> fffff800030904a3 - nt!EnlightenedSwapContext_PatchXSave+2 (+0x1bf)
> [01:21]
> fffff80003090586 - nt!EnlightenedSwapContext_PatchXRstor+2 (+0xe3)
> [09:29]
> 4 errors : !nt (fffff80003090203-fffff80003090586)
>
> MODULE_NAME: memory_corruption
>
> IMAGE_NAME: memory_corruption
>
> FOLLOWUP_NAME: memory_corruption
>
> DEBUG_FLR_IMAGE_TIMESTAMP: 0
>
> MEMORY_CORRUPTOR: ONE_BIT_LARGE
>
> FAILURE_BUCKET_ID: X64_MEMORY_CORRUPTION_ONE_BIT_LARGE
>
> BUCKET_ID: X64_MEMORY_CORRUPTION_ONE_BIT_LARGE
>
> Followup: memory_corruption
> ---------
>
> – mkj
>
> //
> // Michael K. Jones
> // Stone Hill Consulting, LLC
> // http://www.stonehill.com
> //
>
> —
> NTDEV is sponsored by OSR
>
> Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev
>
> OSR is HIRING!! See http://www.osr.com/careers
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>

–
– mkj

//
// Michael K. Jones
// Stone Hill Consulting, LLC
// http://www.stonehill.com
//

Michael_Jones · July 18, 2014, 12:47pm

On 7/18/2014 12:26 PM, Scott Noone wrote:

CODE_CORRUPTION is just the Online Crash Analysis bucket ID, so it’s
just a guess that !analyze makes. An unhandled exception from the
interrupt dispatching code would be highly unusual, so I suspect it’s a
reasonable guess in most of these cases. Clearly in yours though it’s
really unrelated.

OK, good to know. I was worried there was some other underlying problem
here it was trying to tell me about.

RtlStringCbVPrintfA in an ISR would be a Really Bad Idea. Note that the
documentation specifies an IRQL restriction of PASSIVE_LEVEL on that API.

That’s VERY interesting; I didn’t think to look it up (I inherited this
code). Any idea why it’s doc’ed as PASSIVE_LEVEL might help explain other problems I have so far been unable to reproduce>.

–mkj

>
> -scott
> OSR
> @OSRdrivers
>
> “Michael Jones” wrote in message news:xxxxx@ntdev…
>
> Thanks for your response!
>
> The buffer used to format the trace string is on the stack, so not paged
> memory. The code uses RtlStringCbVPrintfA (and checks the return
> value), so not a problem with buffer overflow happening.
>
> I’m not too keen on the fact that the buffer is on the stack; however, I
> don’t believe it’s overflowing the stack. I’ve had that problem in the
> past (with other drivers), and IIRC it’s a pretty explicit bug check,
> which I’m not seeing in this case. Isn’t there a guard page after
> (well, before) the stack?
>
> I will probably change that buffer to not occupy stack space; however,
> it’s not a trivial change since I believe it was originally written that
> way in order to avoid traces from multiple threads stepping on each
> other. So I’m trying to avoid making that sort of change until I get a
> better handle on the bug I’m currently chasing.
>
> Cheers,
>
> --mkj
>
>
> On 7/17/2014 6:20 PM, zhang pei wrote:
>> you are writting log from the isr. check if you are referencing some
>> paged content and if you are writting too much content which over the
>> buffer size.
>>
>>
>>
>> ===================
>> best regards!
>> zhang pei
>>
>>
>> Michael Jones ç¼–å†™ï¼š
>>
>> I’m chasing a problem for a client where a driver for one of their cards
>> hangs when the system starts. I am unable to reproduce it with my
>> hardware (naturally). However, I do get this when start my hardware
>> (which is set up for debugging):
>>
>> Assertion: DPC watchdog timeout
>> This is NOT a break in update time
>> This is most likely a BUG in an ISR
>> Perform a stack trace to find the culprit
>> The period will be doubled on continuation
>> Use gh to continue!!
>>
>> nt! ?? ::FNODOBFM::string'+0x4f3a: >> fffff800030e4b75 cd2c int 2Ch
>>
>> I suspect this is happening because the ISR in this driver spews a lot
>> of messages, and the IRQ is shared with lots of other devices, so this
>> driver’s ISR gets called a lot, only to discover the interrupt is not
>> from it’s device.
>>
>> In any event, I did a “gn”, just to see what the BSOD would look like
>> without Windbg hooked up (in case this is what the client is seeing).
>> The analyze -v is below.
>>
>> I get that the bugcheck is INTERRUPT_EXCEPTION_NOT_HANDLED (since I did
>> a “gn” instead of a “gh”). However, I don’t understand the stuff about
>> CODE_CURRUPTION, and the memory corruption stuff at the end of the
>> analyze. Can anyone enlighten me?
>>
>> TIA, --mkj
>>
>>
>>
>> 0: kd> !analyze -v
>>****************************************************************************
>>
>> *
>> *
>> * Bugcheck Analysis
>> *
>> *
>> *
>> *******************************************************************************
>>
>>
>> INTERRUPT_EXCEPTION_NOT_HANDLED (3d)
>> Arguments:
>> Arg1: fffff80000ba0600
>> Arg2: 0000000000000000
>> Arg3: 0000000000000000
>> Arg4: fffff800030e4b75
>>
>> Debugging Details:
>> ------------------
>>
>>
>> CONTEXT: fffff80000ba0600 – (.cxr 0xfffff80000ba0600)
>> rax=0000001cbc843b72 rbx=fffff800031ffe80 rcx=0000000000000002
>> rdx=0000000000000000 rsi=fffffa800e7a3b60 rdi=0000000000000001
>> rip=fffff800030e4b75 rsp=fffff80000ba0fe0 rbp=0000000000000001
>> r8=0000000000000000 r9=0000000000000000 r10=0000000000000000
>> r11=fffff80000ba10c0 r12=0000000000000000 r13=000000000000000a
>> r14=0000000000000004 r15=0000000000000001
>> iopl=0 nv up ei pl zr na po nc
>> cs=0010 ss=0018 ds=002b es=002b fs=0053 gs=002b
>> efl=00000246
>> nt! ?? ::FNODOBFM::string'+0x4f3a: >> fffff800030e4b75 cd2c int 2Ch
>> Resetting default scope
>>
>> DEFAULT_BUCKET_ID: CODE_CORRUPTION
>>
>> BUGCHECK_STR: 0x3D
>>
>> PROCESS_NAME: LogonUI.exe
>>
>> CURRENT_IRQL: d
>>
>> EXCEPTION_RECORD: fffff80000ba1c58 – (.exr 0xfffff80000ba1c58)
>> ExceptionAddress: fffff800030854b5 (nt!DebugPrint+0x0000000000000015)
>> ExceptionCode: 80000003 (Break instruction exception)
>> ExceptionFlags: 00000000
>> NumberParameters: 1
>> Parameter[0]: 0000000000000001
>>
>> TRAP_FRAME: fffff80000ba1d00 – (.trap 0xfffff80000ba1d00)
>> NOTE: The trap frame does not contain all registers.
>> Some register values may be zeroed or incorrect.
>> rax=0000000000000001 rbx=0000000000000000 rcx=fffff80000ba1f00
>> rdx=000000000000002f rsi=0000000000000000 rdi=0000000000000000
>> rip=fffff800030854b5 rsp=fffff80000ba1e98 rbp=fffff80000ba27b0
>> r8=0000000000000065 r9=0000000000000003 r10=0000000000000000
>> r11=fffff80000ba1db0 r12=0000000000000000 r13=0000000000000000
>> r14=0000000000000000 r15=0000000000000000
>> iopl=0 nv up ei ng nz ac po cy
>> nt!DebugPrint+0x15:
>> fffff800030854b5 c3 ret >> Resetting default scope >> >> LAST_CONTROL_TRANSFER: from fffff80003097eb7 to fffff800030e4b75 >> >> STACK_TEXT: >> fffff80000ba1e98 fffff800030cd675 : 0000000000000000
>> 0000000000000000 0000000000000000 fffff80000ba27b0 : >> nt!DebugPrint+0x15 >> fffff80000ba1ea0 fffff8000313cd0c : 0000000000000000
>> fffff88002fc6e00 fffff80000ba2588 46464646463d2073 : nt! ?? >> ::FNODOBFM::string’+0xc642
>> fffff80000ba2150 fffff88002fbf40b : fffff88002fc6d90 >> fffff80000ba21c0 0000000000000000 00000000fffffffe : nt!DbgPrint+0x3c
>> fffff80000ba2190 fffff88002fbfbda : fffffa8000000005 >> fffff88000000040 fffff88002fc6e00 0000000000000000 :
>> Acrmgpci!DebugPrint+0xcb
>> [c:\clients\xembedded\src\trunk\acrmgpci\driver\driver.c @ 1630]
>> fffff80000ba2570 fffff88002fbfd65 : 00007fff00000000 >> 0000ff1e00000022 fffffa800dbd4af0 fffffa800dbd4af0 :
>> Acrmgpci!LogIsrCode+0x7a
>> [c:\clients\xembedded\src\trunk\acrmgpci\driver\registry.c @ 665]
>> fffff80000ba25d0 fffff88002fbde70 : fffffa800d6a2a80 >> fffffa800d550120 fffffa800daca020 0000000000000000 :
>> Acrmgpci!RunISRCode+0xd5
>> [c:\clients\xembedded\src\trunk\acrmgpci\driver\registry.c @ 714]
>> fffff80000ba26a0 fffff80003089279 : fffffa800d2d8d80 >> fffffa800d6a2a80 fffffa800d2d8d80 0000000000000000 :
>> Acrmgpci!HandleInterrupt+0x30
>> [c:\clients\xembedded\src\trunk\acrmgpci\driver\driver.c @ 441]
>> fffff80000ba26e0 fffff80003089058 : 000000000000001b >> fffff880011289e5 fffff80000ba28a0 fffff8000300d000 :
>> nt!KiScanInterruptObjectList+0x69
>> fffff80000ba2730 fffff800036066f9 : fffff88000fc6a2c >> 0000000000001000 fffffa800d443ac0 fffffa800d44fa20 :
>> nt!KiChainedDispatch+0x128
>> fffff80000ba28c8 fffff88000fc6a2c : 0000000000001000 >> fffffa800d443ac0 fffffa800d44fa20 fffffa800eadbc60 :
>> hal!KeQueryPerformanceCounter+0x5
>> fffff80000ba28d0 fffff88000fd9c7f : fffffa800d440b20 >> 0000000000000000 fffffa800d4409d0 fffffa800eadbc60 :
>> partmgr!PmWmiCounterIoComplete+0x2c
>> fffff80000ba2900 fffff80003090a91 : fffffa800eadbe0b >> fffffa800d4409d0 fffffa800eadbc60 fffffa800eadbc60 : volmgr! ??
>> ::FNODOBFM::string'+0x2cc >> fffff80000ba2940 fffff88001851bce : 000000000000008b
>> 0000000000000001 fffffa800d2e57d0 0000000000000000 : >> nt!IopfCompleteRequest+0x3b1 >> fffff80000ba2a20 fffff80003090a91 : 0000000000000000
>> 0000000000000000 0000000000000000 0000000000000000 : >> CLASSPNP!TransferPktComplete+0x1ce >> fffff80000ba2aa0 fffff8800110641a : fffffa800d2d8540
>> 0000000000000001 fffffa800db24b80 0000000000000000 : >> nt!IopfCompleteRequest+0x3b1 >> fffff80000ba2b80 fffff88001106242 : fffffa800db24b80
>> ffff008004414bda fffffa800d2d8d01 0000000000000000 : >> ataport!IdeCompleteScsiIrp+0x62 >> fffff80000ba2bb0 fffff88001100e32 : 0000000000000002
>> 0000000000000000 0000000000000004 0000ff1e00000004 : >> ataport!IdeCommonCrbCompletion+0x5a >> fffff80000ba2be0 fffff88001109805 : fffffa800d2f31a0
>> fffffa800db24b80 0000000000000000 0000000000000000 : >> ataport!IdeTranslateCompletedRequest+0x236 >> fffff80000ba2d10 fffff88001109104 : fffffa800d2f31a0
>> 0000000000000000 fffffa800d2f31a0 0000000000000000 : >> ataport!IdeProcessCompletedRequests+0x4d5 >> fffff80000ba2e40 fffff80003098b1c : fffff800031ffe80
>> fffffa800dd25000 fffffa800d2f3050 fffffa800d2f3118 : >> ataport!IdePortCompletionDpc+0x1a8 >> fffff80000ba2f00 fffff80003090165 : 0000000000000000
>> fffffa800e7a3b60 0000000000000000 fffff88001108f5c : >> nt!KiRetireDpcList+0x1bc >> fffff80000ba2fb0 fffff8000308ff7c : fffffa800d2d8d80
>> fffff96000096788 0000000025010101 fffff8800287a2a0 : >> nt!KxRetireDpcList+0x5 >> fffff8800287a1e0 fffff800030d9453 : fffff80003089063
>> fffff800030890cf fffffa800e7a3b60 fffff8800287a2a0 : >> nt!KiDispatchInterruptContinue >> fffff8800287a210 fffff800030890cf : fffffa800e7a3b60
>> fffff8800287a2a0 000000000185000f 00000000003085b0 : >> nt!KiDpcInterruptBypass+0x13 >> fffff8800287a220 000007fefbe71c61 : 000000000015f0a8
>> 000000000033f750 000000000015f030 000007fefbd8560f : >> nt!KiChainedDispatch+0x19f >> 000000000015efe0 000007fefbe78ca9 : 0000000000320980
>> 0000000000000000 0000800200000038 0000000000320a20 : >> DUser!DuVisual::GetLogRect+0x296 >> 000000000015f020 000007fefbe78dab : 0000000000000000
>> 0000000000320980 0000000000000000 0000000000320c00 : >> DUser!DuVisual::xrDrawTrivial+0x31 >> 000000000015f080 000007fefbe78c5d : 0000000000000000
>> 0000000000000000 0000000000000000 0000000000000000 : >> DUser!DuVisual::xrDrawTrivial+0x151 >> 000000000015f0e0 000007fefbe79703 : 0000000000000000
>> 0000000000000000 0000000000000000 0000000000000000 : >> DUser!DuVisual::xrDrawFull+0x929 >> 000000000015f290 000007fefbe790d0 : 0000000000000000
>> 0000000000000000 0000000000000001 0000000000000000 : >> DUser!DuVisual::xrDrawFull+0x97d >> 000000000015f440 000007fefbe78ff7 : 0000000000000000
>> 0000000014010099 0000000000000000 0000000000000000 : >> DUser!DuVisual::xrDrawStart+0x58 >> 000000000015f470 000007fefbe78aa7 : 0000000000000001
>> 000000000033f090 0000000014010099 000004b000000640 : >> DUser!DuRootGadget::xrDrawTree+0x51c >> 000000000015f650 000007fefbe71859 : 0000000000000000
>> 0000000000000000 000004b000000000 0000000000000000 : >> DUser!HWndContainer::xdHandleMessage+0x2b4 >> 000000000015f950 00000000777f8971 : 0000000000000000
>> 0000000000000000 0000000000000001 000007fefbe71785 : >> DUser!ExtraInfoWndProc+0x8b >> 000000000015f9b0 00000000777f72cb : 0000000000000000
>> 000007fefbe717e4 0000000000000000 0000000000000000 : >> USER32!UserCallWinProcCheckWow+0x163 >> 000000000015fa70 00000000777f6829 : 0000000000000000
>> 00000000777f919b 0000000000000000 0000000000000001 : >> USER32!DispatchClientMessage+0xc3 >> 000000000015fad0 0000000077931225 : 000000000000000f
>> 0000000000000000 0000000000000000 0000032000006528 : >> USER32!_fnDWORD+0x2d >> 000000000015fb30 00000000777f6e5a : 00000000777f6e6c
>> 00000000000004ff 0000000000000000 0000000000000000 : >> ntdll!KiUserCallbackDispatcherContinue >> 000000000015fbb8 00000000777f6e6c : 00000000000004ff
>> 0000000000000000 0000000000000000 0000000000000001 : >> USER32!ZwUserDispatchMessage+0xa >> 000000000015fbc0 000007fefc7b120b : 0000000000000000
>> 0000000000000000 000007fefbe717e4 0000000000307320 : >> USER32!DispatchMessageWorker+0x55b >> 000000000015fc40 000007fefc7bb0fc : 0000000000000000
>> 0000000000000001 0000000000000000 0000000000000000 : >> authui!CLogonFrame::DoModal+0x13d >> 000000000015fcc0 000007fefc7bb27f : 00000000002f31b0
>> 00000000002e0df0 00000000002db010 00000000002528e6 : >> authui!CLogonUI_CreateThenDoModalThenDestroy+0x299 >> 000000000015fd20 00000000ff6354ff : 00000000002d22f0
>> 00000000002d22f0 0000000000000000 000000000000000b : >> authui!CLogonUI::DoModal+0x73 >> 000000000015fd50 00000000ff635b06 : 0000000000000000
>> 0000000000000000 0000000000000000 00000000ff631178 : >> LogonUI!wWinMain+0xfb >> 000000000015fdb0 00000000776d652d : 0000000000000000
>> 0000000000000000 0000000000000000 0000000000000000 : >> LogonUI!ParseCommandLineToStringArrayLocalAlloc+0x33a >> 000000000015fe70 000000007790c521 : 0000000000000000
>> 0000000000000000 0000000000000000 0000000000000000 : >> kernel32!BaseThreadInitThunk+0xd >> 000000000015fea0 0000000000000000 : 0000000000000000
>> 0000000000000000 0000000000000000 00000000`00000000 :
>> ntdll!RtlUserThreadStart+0x1d
>>
>>
>> STACK_COMMAND: .trap 0xfffff80000ba1d00 ; kb
>>
>> CHKIMG_EXTENSION: !chkimg -lo 50 -d !nt
>> fffff80003090203 - nt!SwapContext_PatchXSave+2
>> [01:21]
>> fffff800030902e4 - nt!SwapContext_PatchXRstor+2 (+0xe1)
>> [09:29]
>> fffff800030904a3 - nt!EnlightenedSwapContext_PatchXSave+2 (+0x1bf)
>> [01:21]
>> fffff80003090586 - nt!EnlightenedSwapContext_PatchXRstor+2 (+0xe3)
>> [09:29]
>> 4 errors : !nt (fffff80003090203-fffff80003090586)
>>
>> MODULE_NAME: memory_corruption
>>
>> IMAGE_NAME: memory_corruption
>>
>> FOLLOWUP_NAME: memory_corruption
>>
>> DEBUG_FLR_IMAGE_TIMESTAMP: 0
>>
>> MEMORY_CORRUPTOR: ONE_BIT_LARGE
>>
>> FAILURE_BUCKET_ID: X64_MEMORY_CORRUPTION_ONE_BIT_LARGE
>>
>> BUCKET_ID: X64_MEMORY_CORRUPTION_ONE_BIT_LARGE
>>
>> Followup: memory_corruption
>> ---------
>>
>> – mkj
>>
>> //
>> // Michael K. Jones
>> // Stone Hill Consulting, LLC
>> // http://www.stonehill.com
>> //
>>
>> —
>> NTDEV is sponsored by OSR
>>
>> Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev
>>
>> OSR is HIRING!! See http://www.osr.com/careers
>>
>> For our schedule of WDF, WDM, debugging and other seminars visit:
>> http://www.osr.com/seminars
>>
>> To unsubscribe, visit the List Server section of OSR Online at
>> http://www.osronline.com/page.cfm?name=ListServer
>>
>

–
– mkj

//
// Michael K. Jones
// Stone Hill Consulting, LLC
// http://www.stonehill.com
//

Ken_Johnson · July 18, 2014, 12:58pm

This CODE_CORRUPTION bucketization is a false positive. The debugging tools version used to generate this !analyze dump doesn’t understand the (expected) code changes made to the xsave code in context swap during system startup, hence the CHKIMG_EXTENSION: lines. Generally, the tools will flag code mismatches as a priority problem if they are discovered, as overwritten code (e.g. from a stray DMA, etc.) manifests in a number of varied failure patterns.

A more recent debugger version resolves this particular false positive problem.

S (Msft)

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Scott Noone
Sent: Friday, July 18, 2014 9:27 AM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] CODE_CORRUPTION in crash dump

CODE_CORRUPTION is just the Online Crash Analysis bucket ID, so it’s just a guess that !analyze makes. An unhandled exception from the interrupt dispatching code would be highly unusual, so I suspect it’s a reasonable guess in most of these cases. Clearly in yours though it’s really unrelated.

RtlStringCbVPrintfA in an ISR would be a Really Bad Idea. Note that the documentation specifies an IRQL restriction of PASSIVE_LEVEL on that API.

-scott
OSR
@OSRdrivers

“Michael Jones” wrote in message news:xxxxx@ntdev…

Thanks for your response!

The buffer used to format the trace string is on the stack, so not paged memory. The code uses RtlStringCbVPrintfA (and checks the return value), so not a problem with buffer overflow happening.

I’m not too keen on the fact that the buffer is on the stack; however, I don’t believe it’s overflowing the stack. I’ve had that problem in the past (with other drivers), and IIRC it’s a pretty explicit bug check, which I’m not seeing in this case. Isn’t there a guard page after (well, before) the stack?

I will probably change that buffer to not occupy stack space; however, it’s not a trivial change since I believe it was originally written that way in order to avoid traces from multiple threads stepping on each other. So I’m trying to avoid making that sort of change until I get a better handle on the bug I’m currently chasing.

Cheers,

–mkj

On 7/17/2014 6:20 PM, zhang pei wrote:

you are writting log from the isr. check if you are referencing some
paged content and if you are writting too much content which over the
buffer size.

===================
best regards!
zhang pei

Michael Jones 编写：
>
> I’m chasing a problem for a client where a driver for one of their
> cards hangs when the system starts. I am unable to reproduce it with
> my hardware (naturally). However, I do get this when start my
> hardware (which is set up for debugging):
>
> Assertion: DPC watchdog timeout
> This is NOT a break in update time
> This is most likely a BUG in an ISR
> Perform a stack trace to find the culprit
> The period will be doubled on continuation
> Use gh to continue!!
>
> nt! ?? ::FNODOBFM::string'+0x4f3a: > fffff800030e4b75 cd2c int 2Ch
>
> I suspect this is happening because the ISR in this driver spews a lot
> of messages, and the IRQ is shared with lots of other devices, so this
> driver’s ISR gets called a lot, only to discover the interrupt is not
> from it’s device.
>
> In any event, I did a “gn”, just to see what the BSOD would look like
> without Windbg hooked up (in case this is what the client is seeing).
> The analyze -v is below.
>
> I get that the bugcheck is INTERRUPT_EXCEPTION_NOT_HANDLED (since I
> did a “gn” instead of a “gh”). However, I don’t understand the stuff
> about CODE_CURRUPTION, and the memory corruption stuff at the end of
> the analyze. Can anyone enlighten me?
>
> TIA, --mkj
>
>
>
> 0: kd> !analyze -v
>***********
>
>
>
> * Bugcheck Analysis
>
>
>
>
> *********
>
> INTERRUPT_EXCEPTION_NOT_HANDLED (3d)
> Arguments:
> Arg1: fffff80000ba0600
> Arg2: 0000000000000000
> Arg3: 0000000000000000
> Arg4: fffff800030e4b75
>
> Debugging Details:
> ------------------
>
>
> CONTEXT: fffff80000ba0600 – (.cxr 0xfffff80000ba0600)
> rax=0000001cbc843b72 rbx=fffff800031ffe80 rcx=0000000000000002
> rdx=0000000000000000 rsi=fffffa800e7a3b60 rdi=0000000000000001
> rip=fffff800030e4b75 rsp=fffff80000ba0fe0 rbp=0000000000000001
> r8=0000000000000000 r9=0000000000000000 r10=0000000000000000
> r11=fffff80000ba10c0 r12=0000000000000000 r13=000000000000000a
> r14=0000000000000004 r15=0000000000000001
> iopl=0 nv up ei pl zr na po nc
> cs=0010 ss=0018 ds=002b es=002b fs=0053 gs=002b
> efl=00000246
> nt! ?? ::FNODOBFM::string'+0x4f3a: > fffff800030e4b75 cd2c int 2Ch
> Resetting default scope
>
> DEFAULT_BUCKET_ID: CODE_CORRUPTION
>
> BUGCHECK_STR: 0x3D
>
> PROCESS_NAME: LogonUI.exe
>
> CURRENT_IRQL: d
>
> EXCEPTION_RECORD: fffff80000ba1c58 – (.exr 0xfffff80000ba1c58)
> ExceptionAddress: fffff800030854b5 (nt!DebugPrint+0x0000000000000015)
> ExceptionCode: 80000003 (Break instruction exception)
> ExceptionFlags: 00000000
> NumberParameters: 1
> Parameter[0]: 0000000000000001
>
> TRAP_FRAME: fffff80000ba1d00 – (.trap 0xfffff80000ba1d00)
> NOTE: The trap frame does not contain all registers.
> Some register values may be zeroed or incorrect.
> rax=0000000000000001 rbx=0000000000000000 rcx=fffff80000ba1f00
> rdx=000000000000002f rsi=0000000000000000 rdi=0000000000000000
> rip=fffff800030854b5 rsp=fffff80000ba1e98 rbp=fffff80000ba27b0
> r8=0000000000000065 r9=0000000000000003 r10=0000000000000000
> r11=fffff80000ba1db0 r12=0000000000000000 r13=0000000000000000
> r14=0000000000000000 r15=0000000000000000
> iopl=0 nv up ei ng nz ac po cy
> nt!DebugPrint+0x15:
> fffff800030854b5 c3 ret > Resetting default scope > > LAST_CONTROL_TRANSFER: from fffff80003097eb7 to fffff800030e4b75 > > STACK_TEXT: > fffff80000ba1e98 fffff800030cd675 : 0000000000000000
> 0000000000000000 0000000000000000 fffff80000ba27b0 : > nt!DebugPrint+0x15 > fffff80000ba1ea0 fffff8000313cd0c : 0000000000000000
> fffff88002fc6e00 fffff80000ba2588 46464646463d2073 : nt! ?? > ::FNODOBFM::string’+0xc642
> fffff80000ba2150 fffff88002fbf40b : fffff88002fc6d90 > fffff80000ba21c0 0000000000000000 00000000fffffffe :
> nt!DbgPrint+0x3c
> fffff80000ba2190 fffff88002fbfbda : fffffa8000000005 > fffff88000000040 fffff88002fc6e00 0000000000000000 :
> Acrmgpci!DebugPrint+0xcb
> [c:\clients\xembedded\src\trunk\acrmgpci\driver\driver.c @ 1630]
> fffff80000ba2570 fffff88002fbfd65 : 00007fff00000000 > 0000ff1e00000022 fffffa800dbd4af0 fffffa800dbd4af0 :
> Acrmgpci!LogIsrCode+0x7a
> [c:\clients\xembedded\src\trunk\acrmgpci\driver\registry.c @ 665]
> fffff80000ba25d0 fffff88002fbde70 : fffffa800d6a2a80 > fffffa800d550120 fffffa800daca020 0000000000000000 :
> Acrmgpci!RunISRCode+0xd5
> [c:\clients\xembedded\src\trunk\acrmgpci\driver\registry.c @ 714]
> fffff80000ba26a0 fffff80003089279 : fffffa800d2d8d80 > fffffa800d6a2a80 fffffa800d2d8d80 0000000000000000 :
> Acrmgpci!HandleInterrupt+0x30
> [c:\clients\xembedded\src\trunk\acrmgpci\driver\driver.c @ 441]
> fffff80000ba26e0 fffff80003089058 : 000000000000001b > fffff880011289e5 fffff80000ba28a0 fffff8000300d000 :
> nt!KiScanInterruptObjectList+0x69
> fffff80000ba2730 fffff800036066f9 : fffff88000fc6a2c > 0000000000001000 fffffa800d443ac0 fffffa800d44fa20 :
> nt!KiChainedDispatch+0x128
> fffff80000ba28c8 fffff88000fc6a2c : 0000000000001000 > fffffa800d443ac0 fffffa800d44fa20 fffffa800eadbc60 :
> hal!KeQueryPerformanceCounter+0x5
> fffff80000ba28d0 fffff88000fd9c7f : fffffa800d440b20 > 0000000000000000 fffffa800d4409d0 fffffa800eadbc60 :
> partmgr!PmWmiCounterIoComplete+0x2c
> fffff80000ba2900 fffff80003090a91 : fffffa800eadbe0b > fffffa800d4409d0 fffffa800eadbc60 fffffa800eadbc60 : volmgr! ??
> ::FNODOBFM::string'+0x2cc > fffff80000ba2940 fffff88001851bce : 000000000000008b
> 0000000000000001 fffffa800d2e57d0 0000000000000000 : > nt!IopfCompleteRequest+0x3b1 > fffff80000ba2a20 fffff80003090a91 : 0000000000000000
> 0000000000000000 0000000000000000 0000000000000000 : > CLASSPNP!TransferPktComplete+0x1ce > fffff80000ba2aa0 fffff8800110641a : fffffa800d2d8540
> 0000000000000001 fffffa800db24b80 0000000000000000 : > nt!IopfCompleteRequest+0x3b1 > fffff80000ba2b80 fffff88001106242 : fffffa800db24b80
> ffff008004414bda fffffa800d2d8d01 0000000000000000 : > ataport!IdeCompleteScsiIrp+0x62 > fffff80000ba2bb0 fffff88001100e32 : 0000000000000002
> 0000000000000000 0000000000000004 0000ff1e00000004 : > ataport!IdeCommonCrbCompletion+0x5a > fffff80000ba2be0 fffff88001109805 : fffffa800d2f31a0
> fffffa800db24b80 0000000000000000 0000000000000000 : > ataport!IdeTranslateCompletedRequest+0x236 > fffff80000ba2d10 fffff88001109104 : fffffa800d2f31a0
> 0000000000000000 fffffa800d2f31a0 0000000000000000 : > ataport!IdeProcessCompletedRequests+0x4d5 > fffff80000ba2e40 fffff80003098b1c : fffff800031ffe80
> fffffa800dd25000 fffffa800d2f3050 fffffa800d2f3118 : > ataport!IdePortCompletionDpc+0x1a8 > fffff80000ba2f00 fffff80003090165 : 0000000000000000
> fffffa800e7a3b60 0000000000000000 fffff88001108f5c : > nt!KiRetireDpcList+0x1bc > fffff80000ba2fb0 fffff8000308ff7c : fffffa800d2d8d80
> fffff96000096788 0000000025010101 fffff8800287a2a0 : > nt!KxRetireDpcList+0x5 > fffff8800287a1e0 fffff800030d9453 : fffff80003089063
> fffff800030890cf fffffa800e7a3b60 fffff8800287a2a0 : > nt!KiDispatchInterruptContinue > fffff8800287a210 fffff800030890cf : fffffa800e7a3b60
> fffff8800287a2a0 000000000185000f 00000000003085b0 : > nt!KiDpcInterruptBypass+0x13 > fffff8800287a220 000007fefbe71c61 : 000000000015f0a8
> 000000000033f750 000000000015f030 000007fefbd8560f : > nt!KiChainedDispatch+0x19f > 000000000015efe0 000007fefbe78ca9 : 0000000000320980
> 0000000000000000 0000800200000038 0000000000320a20 : > DUser!DuVisual::GetLogRect+0x296 > 000000000015f020 000007fefbe78dab : 0000000000000000
> 0000000000320980 0000000000000000 0000000000320c00 : > DUser!DuVisual::xrDrawTrivial+0x31 > 000000000015f080 000007fefbe78c5d : 0000000000000000
> 0000000000000000 0000000000000000 0000000000000000 : > DUser!DuVisual::xrDrawTrivial+0x151 > 000000000015f0e0 000007fefbe79703 : 0000000000000000
> 0000000000000000 0000000000000000 0000000000000000 : > DUser!DuVisual::xrDrawFull+0x929 > 000000000015f290 000007fefbe790d0 : 0000000000000000
> 0000000000000000 0000000000000001 0000000000000000 : > DUser!DuVisual::xrDrawFull+0x97d > 000000000015f440 000007fefbe78ff7 : 0000000000000000
> 0000000014010099 0000000000000000 0000000000000000 : > DUser!DuVisual::xrDrawStart+0x58 > 000000000015f470 000007fefbe78aa7 : 0000000000000001
> 000000000033f090 0000000014010099 000004b000000640 : > DUser!DuRootGadget::xrDrawTree+0x51c > 000000000015f650 000007fefbe71859 : 0000000000000000
> 0000000000000000 000004b000000000 0000000000000000 : > DUser!HWndContainer::xdHandleMessage+0x2b4 > 000000000015f950 00000000777f8971 : 0000000000000000
> 0000000000000000 0000000000000001 000007fefbe71785 : > DUser!ExtraInfoWndProc+0x8b > 000000000015f9b0 00000000777f72cb : 0000000000000000
> 000007fefbe717e4 0000000000000000 0000000000000000 : > USER32!UserCallWinProcCheckWow+0x163 > 000000000015fa70 00000000777f6829 : 0000000000000000
> 00000000777f919b 0000000000000000 0000000000000001 : > USER32!DispatchClientMessage+0xc3 > 000000000015fad0 0000000077931225 : 000000000000000f
> 0000000000000000 0000000000000000 0000032000006528 : > USER32!_fnDWORD+0x2d > 000000000015fb30 00000000777f6e5a : 00000000777f6e6c
> 00000000000004ff 0000000000000000 0000000000000000 : > ntdll!KiUserCallbackDispatcherContinue > 000000000015fbb8 00000000777f6e6c : 00000000000004ff
> 0000000000000000 0000000000000000 0000000000000001 : > USER32!ZwUserDispatchMessage+0xa > 000000000015fbc0 000007fefc7b120b : 0000000000000000
> 0000000000000000 000007fefbe717e4 0000000000307320 : > USER32!DispatchMessageWorker+0x55b > 000000000015fc40 000007fefc7bb0fc : 0000000000000000
> 0000000000000001 0000000000000000 0000000000000000 : > authui!CLogonFrame::DoModal+0x13d > 000000000015fcc0 000007fefc7bb27f : 00000000002f31b0
> 00000000002e0df0 00000000002db010 00000000002528e6 : > authui!CLogonUI_CreateThenDoModalThenDestroy+0x299 > 000000000015fd20 00000000ff6354ff : 00000000002d22f0
> 00000000002d22f0 0000000000000000 000000000000000b : > authui!CLogonUI::DoModal+0x73 > 000000000015fd50 00000000ff635b06 : 0000000000000000
> 0000000000000000 0000000000000000 00000000ff631178 : > LogonUI!wWinMain+0xfb > 000000000015fdb0 00000000776d652d : 0000000000000000
> 0000000000000000 0000000000000000 0000000000000000 : > LogonUI!ParseCommandLineToStringArrayLocalAlloc+0x33a > 000000000015fe70 000000007790c521 : 0000000000000000
> 0000000000000000 0000000000000000 0000000000000000 : > kernel32!BaseThreadInitThunk+0xd > 000000000015fea0 0000000000000000 : 0000000000000000
> 0000000000000000 0000000000000000 00000000`00000000 :
> ntdll!RtlUserThreadStart+0x1d
>
>
> STACK_COMMAND: .trap 0xfffff80000ba1d00 ; kb
>
> CHKIMG_EXTENSION: !chkimg -lo 50 -d !nt
> fffff80003090203 - nt!SwapContext_PatchXSave+2
> [01:21]
> fffff800030902e4 - nt!SwapContext_PatchXRstor+2 (+0xe1)
> [09:29]
> fffff800030904a3 - nt!EnlightenedSwapContext_PatchXSave+2 (+0x1bf)
> [01:21]
> fffff80003090586 - nt!EnlightenedSwapContext_PatchXRstor+2 (+0xe3)
> [09:29]
> 4 errors : !nt (fffff80003090203-fffff80003090586)
>
> MODULE_NAME: memory_corruption
>
> IMAGE_NAME: memory_corruption
>
> FOLLOWUP_NAME: memory_corruption
>
> DEBUG_FLR_IMAGE_TIMESTAMP: 0
>
> MEMORY_CORRUPTOR: ONE_BIT_LARGE
>
> FAILURE_BUCKET_ID: X64_MEMORY_CORRUPTION_ONE_BIT_LARGE
>
> BUCKET_ID: X64_MEMORY_CORRUPTION_ONE_BIT_LARGE
>
> Followup: memory_corruption
> ---------
>
> – mkj
>
> //
> // Michael K. Jones
> // Stone Hill Consulting, LLC
> // http://www.stonehill.com
> //
>
> —
> NTDEV is sponsored by OSR
>
> Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev
>
> OSR is HIRING!! See http://www.osr.com/careers
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>

–
– mkj

//
// Michael K. Jones
// Stone Hill Consulting, LLC
// http://www.stonehill.com
//

—
NTDEV is sponsored by OSR

Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev

OSR is HIRING!! See http://www.osr.com/careers

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

Mark_Roddy · July 18, 2014, 2:17pm

It is doc’d as passive level because for example Unicode string formatting
(%wZ) can cause a page fault.

Mark Roddy

On Fri, Jul 18, 2014 at 12:46 PM, Michael Jones
wrote:

> On 7/18/2014 12:26 PM, Scott Noone wrote:
>
>> CODE_CORRUPTION is just the Online Crash Analysis bucket ID, so it’s
>> just a guess that !analyze makes. An unhandled exception from the
>> interrupt dispatching code would be highly unusual, so I suspect it’s a
>> reasonable guess in most of these cases. Clearly in yours though it’s
>> really unrelated.
>>
>
> OK, good to know. I was worried there was some other underlying problem
> here it was trying to tell me about.
>
>
>
>> RtlStringCbVPrintfA in an ISR would be a Really Bad Idea. Note that the
>> documentation specifies an IRQL restriction of PASSIVE_LEVEL on that API.
>>
>
> That’s VERY interesting; I didn’t think to look it up (I inherited this
> code). Any idea why it’s doc’ed as PASSIVE_LEVEL > might help explain other problems I have so far been unable to reproduce>.
>
> --mkj
>
>
>
>> -scott
>> OSR
>> @OSRdrivers
>>
>> “Michael Jones” wrote in message news:xxxxx@ntdev…
>>
>> Thanks for your response!
>>
>> The buffer used to format the trace string is on the stack, so not paged
>> memory. The code uses RtlStringCbVPrintfA (and checks the return
>> value), so not a problem with buffer overflow happening.
>>
>> I’m not too keen on the fact that the buffer is on the stack; however, I
>> don’t believe it’s overflowing the stack. I’ve had that problem in the
>> past (with other drivers), and IIRC it’s a pretty explicit bug check,
>> which I’m not seeing in this case. Isn’t there a guard page after
>> (well, before) the stack?
>>
>> I will probably change that buffer to not occupy stack space; however,
>> it’s not a trivial change since I believe it was originally written that
>> way in order to avoid traces from multiple threads stepping on each
>> other. So I’m trying to avoid making that sort of change until I get a
>> better handle on the bug I’m currently chasing.
>>
>> Cheers,
>>
>> --mkj
>>
>>
>> On 7/17/2014 6:20 PM, zhang pei wrote:
>>
>>> you are writting log from the isr. check if you are referencing some
>>> paged content and if you are writting too much content which over the
>>> buffer size.
>>>
>>>
>>>
>>> ===================
>>> best regards!
>>> zhang pei
>>>
>>>
>>> Michael Jones 编写：
>>>
>>> I’m chasing a problem for a client where a driver for one of their cards
>>> hangs when the system starts. I am unable to reproduce it with my
>>> hardware (naturally). However, I do get this when start my hardware
>>> (which is set up for debugging):
>>>
>>> Assertion: DPC watchdog timeout
>>> This is NOT a break in update time
>>> This is most likely a BUG in an ISR
>>> Perform a stack trace to find the culprit
>>> The period will be doubled on continuation
>>> Use gh to continue!!
>>>
>>> nt! ?? ::FNODOBFM::string'+0x4f3a: >>> fffff800030e4b75 cd2c int 2Ch
>>>
>>> I suspect this is happening because the ISR in this driver spews a lot
>>> of messages, and the IRQ is shared with lots of other devices, so this
>>> driver’s ISR gets called a lot, only to discover the interrupt is not
>>> from it’s device.
>>>
>>> In any event, I did a “gn”, just to see what the BSOD would look like
>>> without Windbg hooked up (in case this is what the client is seeing).
>>> The analyze -v is below.
>>>
>>> I get that the bugcheck is INTERRUPT_EXCEPTION_NOT_HANDLED (since I did
>>> a “gn” instead of a “gh”). However, I don’t understand the stuff about
>>> CODE_CURRUPTION, and the memory corruption stuff at the end of the
>>> analyze. Can anyone enlighten me?
>>>
>>> TIA, --mkj
>>>
>>>
>>>
>>> 0: kd> !analyze -v
>>>*********************
>>>
>>>
>>>
>>>
>>> * Bugcheck Analysis
>>>
>>>
>>>
>>>
>>> *******************
>>>
>>>
>>> INTERRUPT_EXCEPTION_NOT_HANDLED (3d)
>>> Arguments:
>>> Arg1: fffff80000ba0600
>>> Arg2: 0000000000000000
>>> Arg3: 0000000000000000
>>> Arg4: fffff800030e4b75
>>>
>>> Debugging Details:
>>> ------------------
>>>
>>>
>>> CONTEXT: fffff80000ba0600 – (.cxr 0xfffff80000ba0600)
>>> rax=0000001cbc843b72 rbx=fffff800031ffe80 rcx=0000000000000002
>>> rdx=0000000000000000 rsi=fffffa800e7a3b60 rdi=0000000000000001
>>> rip=fffff800030e4b75 rsp=fffff80000ba0fe0 rbp=0000000000000001
>>> r8=0000000000000000 r9=0000000000000000 r10=0000000000000000
>>> r11=fffff80000ba10c0 r12=0000000000000000 r13=000000000000000a
>>> r14=0000000000000004 r15=0000000000000001
>>> iopl=0 nv up ei pl zr na po nc
>>> cs=0010 ss=0018 ds=002b es=002b fs=0053 gs=002b
>>> efl=00000246
>>> nt! ?? ::FNODOBFM::string'+0x4f3a: >>> fffff800030e4b75 cd2c int 2Ch
>>> Resetting default scope
>>>
>>> DEFAULT_BUCKET_ID: CODE_CORRUPTION
>>>
>>> BUGCHECK_STR: 0x3D
>>>
>>> PROCESS_NAME: LogonUI.exe
>>>
>>> CURRENT_IRQL: d
>>>
>>> EXCEPTION_RECORD: fffff80000ba1c58 – (.exr 0xfffff80000ba1c58)
>>> ExceptionAddress: fffff800030854b5 (nt!DebugPrint+0x0000000000000015)
>>> ExceptionCode: 80000003 (Break instruction exception)
>>> ExceptionFlags: 00000000
>>> NumberParameters: 1
>>> Parameter[0]: 0000000000000001
>>>
>>> TRAP_FRAME: fffff80000ba1d00 – (.trap 0xfffff80000ba1d00)
>>> NOTE: The trap frame does not contain all registers.
>>> Some register values may be zeroed or incorrect.
>>> rax=0000000000000001 rbx=0000000000000000 rcx=fffff80000ba1f00
>>> rdx=000000000000002f rsi=0000000000000000 rdi=0000000000000000
>>> rip=fffff800030854b5 rsp=fffff80000ba1e98 rbp=fffff80000ba27b0
>>> r8=0000000000000065 r9=0000000000000003 r10=0000000000000000
>>> r11=fffff80000ba1db0 r12=0000000000000000 r13=0000000000000000
>>> r14=0000000000000000 r15=0000000000000000
>>> iopl=0 nv up ei ng nz ac po cy
>>> nt!DebugPrint+0x15:
>>> fffff800030854b5 c3 ret >>> Resetting default scope >>> >>> LAST_CONTROL_TRANSFER: from fffff80003097eb7 to fffff800030e4b75 >>> >>> STACK_TEXT: >>> fffff80000ba1e98 fffff800030cd675 : 0000000000000000
>>> 0000000000000000 0000000000000000 fffff80000ba27b0 : >>> nt!DebugPrint+0x15 >>> fffff80000ba1ea0 fffff8000313cd0c : 0000000000000000
>>> fffff88002fc6e00 fffff80000ba2588 46464646463d2073 : nt! ?? >>> ::FNODOBFM::string’+0xc642
>>> fffff80000ba2150 fffff88002fbf40b : fffff88002fc6d90 >>> fffff80000ba21c0 0000000000000000 00000000fffffffe : nt!DbgPrint+0x3c
>>> fffff80000ba2190 fffff88002fbfbda : fffffa8000000005 >>> fffff88000000040 fffff88002fc6e00 0000000000000000 :
>>> Acrmgpci!DebugPrint+0xcb
>>> [c:\clients\xembedded\src\trunk\acrmgpci\driver\driver.c @ 1630]
>>> fffff80000ba2570 fffff88002fbfd65 : 00007fff00000000 >>> 0000ff1e00000022 fffffa800dbd4af0 fffffa800dbd4af0 :
>>> Acrmgpci!LogIsrCode+0x7a
>>> [c:\clients\xembedded\src\trunk\acrmgpci\driver\registry.c @ 665]
>>> fffff80000ba25d0 fffff88002fbde70 : fffffa800d6a2a80 >>> fffffa800d550120 fffffa800daca020 0000000000000000 :
>>> Acrmgpci!RunISRCode+0xd5
>>> [c:\clients\xembedded\src\trunk\acrmgpci\driver\registry.c @ 714]
>>> fffff80000ba26a0 fffff80003089279 : fffffa800d2d8d80 >>> fffffa800d6a2a80 fffffa800d2d8d80 0000000000000000 :
>>> Acrmgpci!HandleInterrupt+0x30
>>> [c:\clients\xembedded\src\trunk\acrmgpci\driver\driver.c @ 441]
>>> fffff80000ba26e0 fffff80003089058 : 000000000000001b >>> fffff880011289e5 fffff80000ba28a0 fffff8000300d000 :
>>> nt!KiScanInterruptObjectList+0x69
>>> fffff80000ba2730 fffff800036066f9 : fffff88000fc6a2c >>> 0000000000001000 fffffa800d443ac0 fffffa800d44fa20 :
>>> nt!KiChainedDispatch+0x128
>>> fffff80000ba28c8 fffff88000fc6a2c : 0000000000001000 >>> fffffa800d443ac0 fffffa800d44fa20 fffffa800eadbc60 :
>>> hal!KeQueryPerformanceCounter+0x5
>>> fffff80000ba28d0 fffff88000fd9c7f : fffffa800d440b20 >>> 0000000000000000 fffffa800d4409d0 fffffa800eadbc60 :
>>> partmgr!PmWmiCounterIoComplete+0x2c
>>> fffff80000ba2900 fffff80003090a91 : fffffa800eadbe0b >>> fffffa800d4409d0 fffffa800eadbc60 fffffa800eadbc60 : volmgr! ??
>>> ::FNODOBFM::string'+0x2cc >>> fffff80000ba2940 fffff88001851bce : 000000000000008b
>>> 0000000000000001 fffffa800d2e57d0 0000000000000000 : >>> nt!IopfCompleteRequest+0x3b1 >>> fffff80000ba2a20 fffff80003090a91 : 0000000000000000
>>> 0000000000000000 0000000000000000 0000000000000000 : >>> CLASSPNP!TransferPktComplete+0x1ce >>> fffff80000ba2aa0 fffff8800110641a : fffffa800d2d8540
>>> 0000000000000001 fffffa800db24b80 0000000000000000 : >>> nt!IopfCompleteRequest+0x3b1 >>> fffff80000ba2b80 fffff88001106242 : fffffa800db24b80
>>> ffff008004414bda fffffa800d2d8d01 0000000000000000 : >>> ataport!IdeCompleteScsiIrp+0x62 >>> fffff80000ba2bb0 fffff88001100e32 : 0000000000000002
>>> 0000000000000000 0000000000000004 0000ff1e00000004 : >>> ataport!IdeCommonCrbCompletion+0x5a >>> fffff80000ba2be0 fffff88001109805 : fffffa800d2f31a0
>>> fffffa800db24b80 0000000000000000 0000000000000000 : >>> ataport!IdeTranslateCompletedRequest+0x236 >>> fffff80000ba2d10 fffff88001109104 : fffffa800d2f31a0
>>> 0000000000000000 fffffa800d2f31a0 0000000000000000 : >>> ataport!IdeProcessCompletedRequests+0x4d5 >>> fffff80000ba2e40 fffff80003098b1c : fffff800031ffe80
>>> fffffa800dd25000 fffffa800d2f3050 fffffa800d2f3118 : >>> ataport!IdePortCompletionDpc+0x1a8 >>> fffff80000ba2f00 fffff80003090165 : 0000000000000000
>>> fffffa800e7a3b60 0000000000000000 fffff88001108f5c : >>> nt!KiRetireDpcList+0x1bc >>> fffff80000ba2fb0 fffff8000308ff7c : fffffa800d2d8d80
>>> fffff96000096788 0000000025010101 fffff8800287a2a0 : >>> nt!KxRetireDpcList+0x5 >>> fffff8800287a1e0 fffff800030d9453 : fffff80003089063
>>> fffff800030890cf fffffa800e7a3b60 fffff8800287a2a0 : >>> nt!KiDispatchInterruptContinue >>> fffff8800287a210 fffff800030890cf : fffffa800e7a3b60
>>> fffff8800287a2a0 000000000185000f 00000000003085b0 : >>> nt!KiDpcInterruptBypass+0x13 >>> fffff8800287a220 000007fefbe71c61 : 000000000015f0a8
>>> 000000000033f750 000000000015f030 000007fefbd8560f : >>> nt!KiChainedDispatch+0x19f >>> 000000000015efe0 000007fefbe78ca9 : 0000000000320980
>>> 0000000000000000 0000800200000038 0000000000320a20 : >>> DUser!DuVisual::GetLogRect+0x296 >>> 000000000015f020 000007fefbe78dab : 0000000000000000
>>> 0000000000320980 0000000000000000 0000000000320c00 : >>> DUser!DuVisual::xrDrawTrivial+0x31 >>> 000000000015f080 000007fefbe78c5d : 0000000000000000
>>> 0000000000000000 0000000000000000 0000000000000000 : >>> DUser!DuVisual::xrDrawTrivial+0x151 >>> 000000000015f0e0 000007fefbe79703 : 0000000000000000
>>> 0000000000000000 0000000000000000 0000000000000000 : >>> DUser!DuVisual::xrDrawFull+0x929 >>> 000000000015f290 000007fefbe790d0 : 0000000000000000
>>> 0000000000000000 0000000000000001 0000000000000000 : >>> DUser!DuVisual::xrDrawFull+0x97d >>> 000000000015f440 000007fefbe78ff7 : 0000000000000000
>>> 0000000014010099 0000000000000000 0000000000000000 : >>> DUser!DuVisual::xrDrawStart+0x58 >>> 000000000015f470 000007fefbe78aa7 : 0000000000000001
>>> 000000000033f090 0000000014010099 000004b000000640 : >>> DUser!DuRootGadget::xrDrawTree+0x51c >>> 000000000015f650 000007fefbe71859 : 0000000000000000
>>> 0000000000000000 000004b000000000 0000000000000000 : >>> DUser!HWndContainer::xdHandleMessage+0x2b4 >>> 000000000015f950 00000000777f8971 : 0000000000000000
>>> 0000000000000000 0000000000000001 000007fefbe71785 : >>> DUser!ExtraInfoWndProc+0x8b >>> 000000000015f9b0 00000000777f72cb : 0000000000000000
>>> 000007fefbe717e4 0000000000000000 0000000000000000 : >>> USER32!UserCallWinProcCheckWow+0x163 >>> 000000000015fa70 00000000777f6829 : 0000000000000000
>>> 00000000777f919b 0000000000000000 0000000000000001 : >>> USER32!DispatchClientMessage+0xc3 >>> 000000000015fad0 0000000077931225 : 000000000000000f
>>> 0000000000000000 0000000000000000 0000032000006528 : >>> USER32!_fnDWORD+0x2d >>> 000000000015fb30 00000000777f6e5a : 00000000777f6e6c
>>> 00000000000004ff 0000000000000000 0000000000000000 : >>> ntdll!KiUserCallbackDispatcherContinue >>> 000000000015fbb8 00000000777f6e6c : 00000000000004ff
>>> 0000000000000000 0000000000000000 0000000000000001 : >>> USER32!ZwUserDispatchMessage+0xa >>> 000000000015fbc0 000007fefc7b120b : 0000000000000000
>>> 0000000000000000 000007fefbe717e4 0000000000307320 : >>> USER32!DispatchMessageWorker+0x55b >>> 000000000015fc40 000007fefc7bb0fc : 0000000000000000
>>> 0000000000000001 0000000000000000 0000000000000000 : >>> authui!CLogonFrame::DoModal+0x13d >>> 000000000015fcc0 000007fefc7bb27f : 00000000002f31b0
>>> 00000000002e0df0 00000000002db010 00000000002528e6 : >>> authui!CLogonUI_CreateThenDoModalThenDestroy+0x299 >>> 000000000015fd20 00000000ff6354ff : 00000000002d22f0
>>> 00000000002d22f0 0000000000000000 000000000000000b : >>> authui!CLogonUI::DoModal+0x73 >>> 000000000015fd50 00000000ff635b06 : 0000000000000000
>>> 0000000000000000 0000000000000000 00000000ff631178 : >>> LogonUI!wWinMain+0xfb >>> 000000000015fdb0 00000000776d652d : 0000000000000000
>>> 0000000000000000 0000000000000000 0000000000000000 : >>> LogonUI!ParseCommandLineToStringArrayLocalAlloc+0x33a >>> 000000000015fe70 000000007790c521 : 0000000000000000
>>> 0000000000000000 0000000000000000 0000000000000000 : >>> kernel32!BaseThreadInitThunk+0xd >>> 000000000015fea0 0000000000000000 : 0000000000000000
>>> 0000000000000000 0000000000000000 00000000`00000000 :
>>> ntdll!RtlUserThreadStart+0x1d
>>>
>>>
>>> STACK_COMMAND: .trap 0xfffff80000ba1d00 ; kb
>>>
>>> CHKIMG_EXTENSION: !chkimg -lo 50 -d !nt
>>> fffff80003090203 - nt!SwapContext_PatchXSave+2
>>> [01:21]
>>> fffff800030902e4 - nt!SwapContext_PatchXRstor+2 (+0xe1)
>>> [09:29]
>>> fffff800030904a3 - nt!EnlightenedSwapContext_PatchXSave+2 (+0x1bf)
>>> [01:21]
>>> fffff80003090586 - nt!EnlightenedSwapContext_PatchXRstor+2 (+0xe3)
>>> [09:29]
>>> 4 errors : !nt (fffff80003090203-fffff80003090586)
>>>
>>> MODULE_NAME: memory_corruption
>>>
>>> IMAGE_NAME: memory_corruption
>>>
>>> FOLLOWUP_NAME: memory_corruption
>>>
>>> DEBUG_FLR_IMAGE_TIMESTAMP: 0
>>>
>>> MEMORY_CORRUPTOR: ONE_BIT_LARGE
>>>
>>> FAILURE_BUCKET_ID: X64_MEMORY_CORRUPTION_ONE_BIT_LARGE
>>>
>>> BUCKET_ID: X64_MEMORY_CORRUPTION_ONE_BIT_LARGE
>>>
>>> Followup: memory_corruption
>>> ---------
>>>
>>> – mkj
>>>
>>> //
>>> // Michael K. Jones
>>> // Stone Hill Consulting, LLC
>>> // http://www.stonehill.com
>>> //
>>>
>>> —
>>> NTDEV is sponsored by OSR
>>>
>>> Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev
>>>
>>> OSR is HIRING!! See http://www.osr.com/careers
>>>
>>> For our schedule of WDF, WDM, debugging and other seminars visit:
>>> http://www.osr.com/seminars
>>>
>>> To unsubscribe, visit the List Server section of OSR Online at
>>> http://www.osronline.com/page.cfm?name=ListServer
>>>
>>>
>>
> –
> – mkj
>
> //
> // Michael K. Jones
> // Stone Hill Consulting, LLC
> // http://www.stonehill.com
> //
>
> —
> NTDEV is sponsored by OSR
>
> Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev
>
> OSR is HIRING!! See http://www.osr.com/careers
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>

Michael_Jones · July 18, 2014, 2:37pm

I guess what I’m wondering is what might happen if it is called at
DIRQL? In this case, I know it’s not formatting Unicode strings (the
strings used are all ANSI). In addition, it’s formatting numeric values
(as hex, generally).

If it’s just formatting Unicode strings that get you into trouble at
DIRQL, then I still need to find some other explanation for the problems
the client is seeing. In any case, I will be fixing this (since at best
it’s a BSOD waiting to happen).

I was just hoping to have found a smoking gun

Thanks,

–mkj

On 7/18/2014 2:17 PM, Mark Roddy wrote:

It is doc’d as passive level because for example Unicode string
formatting (%wZ) can cause a page fault.

Mark Roddy

On Fri, Jul 18, 2014 at 12:46 PM, Michael Jones > mailto:xxxxx> wrote:
>
> On 7/18/2014 12:26 PM, Scott Noone wrote:
>
> CODE_CORRUPTION is just the Online Crash Analysis bucket ID, so it’s
> just a guess that !analyze makes. An unhandled exception from the
> interrupt dispatching code would be highly unusual, so I suspect
> it’s a
> reasonable guess in most of these cases. Clearly in yours though
> it’s
> really unrelated.
>
>
> OK, good to know. I was worried there was some other underlying
> problem here it was trying to tell me about.
>
>
>
> RtlStringCbVPrintfA in an ISR would be a Really Bad Idea. Note
> that the
> documentation specifies an IRQL restriction of PASSIVE_LEVEL on
> that API.
>
>
> That’s VERY interesting; I didn’t think to look it up (I inherited
> this code). Any idea why it’s doc’ed as PASSIVE_LEVEL > hoping it might help explain other problems I have so far been
> unable to reproduce>.
>
> --mkj
>
>
>
> -scott
> OSR
> @OSRdrivers
>
> “Michael Jones” wrote in message news:xxxxx@ntdev…
>
> Thanks for your response!
>
> The buffer used to format the trace string is on the stack, so
> not paged
> memory. The code uses RtlStringCbVPrintfA (and checks the return
> value), so not a problem with buffer overflow happening.
>
> I’m not too keen on the fact that the buffer is on the stack;
> however, I
> don’t believe it’s overflowing the stack. I’ve had that problem
> in the
> past (with other drivers), and IIRC it’s a pretty explicit bug
> check,
> which I’m not seeing in this case. Isn’t there a guard page after
> (well, before) the stack?
>
> I will probably change that buffer to not occupy stack space;
> however,
> it’s not a trivial change since I believe it was originally
> written that
> way in order to avoid traces from multiple threads stepping on each
> other. So I’m trying to avoid making that sort of change until
> I get a
> better handle on the bug I’m currently chasing.
>
> Cheers,
>
> --mkj
>
>
> On 7/17/2014 6:20 PM, zhang pei wrote:
>
> you are writting log from the isr. check if you are
> referencing some
> paged content and if you are writting too much content which
> over the
> buffer size.
>
>
>
> ===================
> best regards!
> zhang pei
>
>
> Michael Jones > mailto:xxxxx>ç¼–å†™ï¼š
>
> I’m chasing a problem for a client where a driver for one of
> their cards
> hangs when the system starts. I am unable to reproduce it
> with my
> hardware (naturally). However, I do get this when start my
> hardware
> (which is set up for debugging):
>
> Assertion: DPC watchdog timeout
> This is NOT a break in update time
> This is most likely a BUG in an ISR
> Perform a stack trace to find the culprit
> The period will be doubled on continuation
> Use gh to continue!!
>
> nt! ?? ::FNODOBFM::string'+0x4f3a: > fffff800030e4b75 cd2c int 2Ch
>
> I suspect this is happening because the ISR in this driver
> spews a lot
> of messages, and the IRQ is shared with lots of other
> devices, so this
> driver’s ISR gets called a lot, only to discover the
> interrupt is not
> from it’s device.
>
> In any event, I did a “gn”, just to see what the BSOD would
> look like
> without Windbg hooked up (in case this is what the client is
> seeing).
> The analyze -v is below.
>
> I get that the bugcheck is INTERRUPT_EXCEPTION_NOT___HANDLED
> (since I did
> a “gn” instead of a “gh”). However, I don’t understand the
> stuff about
> CODE_CURRUPTION, and the memory corruption stuff at the end
> of the
> analyze. Can anyone enlighten me?
>
> TIA, --mkj
>
>
>
> 0: kd> !analyze -v
>********__ ****************************** __
>
> *
> *
> * Bugcheck Analysis
> *
> *
> *
> ***********__ ****************************** __
>
>
> INTERRUPT_EXCEPTION_NOT___ HANDLED (3d)
> Arguments:
> Arg1: fffff80000ba0600
> Arg2: 0000000000000000
> Arg3: 0000000000000000
> Arg4: fffff800030e4b75
>
> Debugging Details:
> ------------------
>
>
> CONTEXT: fffff80000ba0600 – (.cxr 0xfffff80000ba0600)
> rax=0000001cbc843b72 rbx=fffff800031ffe80 rcx=0000000000000002
> rdx=0000000000000000 rsi=fffffa800e7a3b60 rdi=0000000000000001
> rip=fffff800030e4b75 rsp=fffff80000ba0fe0 rbp=0000000000000001
> r8=0000000000000000 r9=0000000000000000
> r10=0000000000000000
> r11=fffff80000ba10c0 r12=0000000000000000 r13=000000000000000a
> r14=0000000000000004 r15=0000000000000001
> iopl=0 nv up ei pl zr na po nc
> cs=0010 ss=0018 ds=002b es=002b fs=0053 gs=002b
> efl=00000246
> nt! ?? ::FNODOBFM::string'+0x4f3a: > fffff800030e4b75 cd2c int 2Ch
> Resetting default scope
>
> DEFAULT_BUCKET_ID: CODE_CORRUPTION
>
> BUGCHECK_STR: 0x3D
>
> PROCESS_NAME: LogonUI.exe
>
> CURRENT_IRQL: d
>
> EXCEPTION_RECORD: fffff80000ba1c58 – (.exr 0xfffff80000ba1c58)
> ExceptionAddress: fffff800030854b5
> (nt!DebugPrint+0x0000000000000015)
> ExceptionCode: 80000003 (Break instruction exception)
> ExceptionFlags: 00000000
> NumberParameters: 1
> Parameter[0]: 0000000000000001
>
> TRAP_FRAME: fffff80000ba1d00 – (.trap 0xfffff80000ba1d00)
> NOTE: The trap frame does not contain all registers.
> Some register values may be zeroed or incorrect.
> rax=0000000000000001 rbx=0000000000000000 rcx=fffff80000ba1f00
> rdx=000000000000002f rsi=0000000000000000 rdi=0000000000000000
> rip=fffff800030854b5 rsp=fffff80000ba1e98 rbp=fffff80000ba27b0
> r8=0000000000000065 r9=0000000000000003
> r10=0000000000000000
> r11=fffff80000ba1db0 r12=0000000000000000 r13=0000000000000000
> r14=0000000000000000 r15=0000000000000000
> iopl=0 nv up ei ng nz ac po cy
> nt!DebugPrint+0x15:
> fffff800030854b5 c3 ret > Resetting default scope > > LAST_CONTROL_TRANSFER: from fffff80003097eb7 to > fffff800030e4b75 > > STACK_TEXT: > fffff80000ba1e98 fffff800030cd675 : 0000000000000000
> 0000000000000000 0000000000000000 fffff80000ba27b0 : > nt!DebugPrint+0x15 > fffff80000ba1ea0 fffff8000313cd0c : 0000000000000000
> fffff88002fc6e00 fffff80000ba2588 46464646463d2073 : nt! ?? > ::FNODOBFM::string’+0xc642
> fffff80000ba2150 fffff88002fbf40b : fffff88002fc6d90 > fffff80000ba21c0 0000000000000000 00000000fffffffe :
> nt!DbgPrint+0x3c
> fffff80000ba2190 fffff88002fbfbda : fffffa8000000005 > fffff88000000040 fffff88002fc6e00 0000000000000000 :
> Acrmgpci!DebugPrint+0xcb
> [c:\clients\xembedded\src__trunk\acrmgpci\driver\driver.c @
> 1630]
> fffff80000ba2570 fffff88002fbfd65 : 00007fff00000000 > 0000ff1e00000022 fffffa800dbd4af0 fffffa800dbd4af0 :
> Acrmgpci!LogIsrCode+0x7a
> [c:\clients\xembedded\src\ trunk\acrmgpci\driver registry.c
> @ 665]
> fffff80000ba25d0 fffff88002fbde70 : fffffa800d6a2a80 > fffffa800d550120 fffffa800daca020 0000000000000000 :
> Acrmgpci!RunISRCode+0xd5
> [c:\clients\xembedded\src\ trunk\acrmgpci\driver registry.c
> @ 714]
> fffff80000ba26a0 fffff80003089279 : fffffa800d2d8d80 > fffffa800d6a2a80 fffffa800d2d8d80 0000000000000000 :
> Acrmgpci!HandleInterrupt+0x30
> [c:\clients\xembedded\src__trunk\acrmgpci\driver\driver.c @
> 441]
> fffff80000ba26e0 fffff80003089058 : 000000000000001b > fffff880011289e5 fffff80000ba28a0 fffff8000300d000 :
> nt!KiScanInterruptObjectList+0x69
> fffff80000ba2730 fffff800036066f9 : fffff88000fc6a2c > 0000000000001000 fffffa800d443ac0 fffffa800d44fa20 :
> nt!KiChainedDispatch+0x128
> fffff80000ba28c8 fffff88000fc6a2c : 0000000000001000 > fffffa800d443ac0 fffffa800d44fa20 fffffa800eadbc60 :
> hal!KeQueryPerformanceCounter+ 0x5
> fffff80000ba28d0 fffff88000fd9c7f : fffffa800d440b20 > 0000000000000000 fffffa800d4409d0 fffffa800eadbc60 :
> partmgr! PmWmiCounterIoComplete+0x2c
> fffff80000ba2900 fffff80003090a91 : fffffa800eadbe0b > fffffa800d4409d0 fffffa800eadbc60 fffffa800eadbc60 :
> volmgr! ??
> ::FNODOBFM::string'+0x2cc > fffff80000ba2940 fffff88001851bce : 000000000000008b
> 0000000000000001 fffffa800d2e57d0 0000000000000000 : > nt!IopfCompleteRequest+0x3b1 > fffff80000ba2a20 fffff80003090a91 : 0000000000000000
> 0000000000000000 0000000000000000 0000000000000000 : > CLASSPNP!TransferPktComplete+ __0x1ce > fffff80000ba2aa0 fffff8800110641a : fffffa800d2d8540
> 0000000000000001 fffffa800db24b80 0000000000000000 : > nt!IopfCompleteRequest+0x3b1 > fffff80000ba2b80 fffff88001106242 : fffffa800db24b80
> ffff008004414bda fffffa800d2d8d01 0000000000000000 : > ataport!IdeCompleteScsiIrp+__ 0x62 > fffff80000ba2bb0 fffff88001100e32 : 0000000000000002
> 0000000000000000 0000000000000004 0000ff1e00000004 : > ataport! __IdeCommonCrbCompletion+0x5a > fffff80000ba2be0 fffff88001109805 : fffffa800d2f31a0
> fffffa800db24b80 0000000000000000 0000000000000000 : > ataport!__ IdeTranslateCompletedRequest+ __0x236 > fffff80000ba2d10 fffff88001109104 : fffffa800d2f31a0
> 0000000000000000 fffffa800d2f31a0 0000000000000000 : > ataport!__ IdeProcessCompletedRequests+ __0x4d5 > fffff80000ba2e40 fffff80003098b1c : fffff800031ffe80
> fffffa800dd25000 fffffa800d2f3050 fffffa800d2f3118 : > ataport!IdePortCompletionDpc+__ 0x1a8 > fffff80000ba2f00 fffff80003090165 : 0000000000000000
> fffffa800e7a3b60 0000000000000000 fffff88001108f5c : > nt!KiRetireDpcList+0x1bc > fffff80000ba2fb0 fffff8000308ff7c : fffffa800d2d8d80
> fffff96000096788 0000000025010101 fffff8800287a2a0 : > nt!KxRetireDpcList+0x5 > fffff8800287a1e0 fffff800030d9453 : fffff80003089063
> fffff800030890cf fffffa800e7a3b60 fffff8800287a2a0 : > nt!KiDispatchInterruptContinue > fffff8800287a210 fffff800030890cf : fffffa800e7a3b60
> fffff8800287a2a0 000000000185000f 00000000003085b0 : > nt!KiDpcInterruptBypass+0x13 > fffff8800287a220 000007fefbe71c61 : 000000000015f0a8
> 000000000033f750 000000000015f030 000007fefbd8560f : > nt!KiChainedDispatch+0x19f > 000000000015efe0 000007fefbe78ca9 : 0000000000320980
> 0000000000000000 0000800200000038 0000000000320a20 : > DUser!DuVisual::GetLogRect+ __0x296 > 000000000015f020 000007fefbe78dab : 0000000000000000
> 0000000000320980 0000000000000000 0000000000320c00 : > DUser!DuVisual::xrDrawTrivial+__ 0x31 > 000000000015f080 000007fefbe78c5d : 0000000000000000
> 0000000000000000 0000000000000000 0000000000000000 : > DUser!DuVisual::xrDrawTrivial+ __0x151 > 000000000015f0e0 000007fefbe79703 : 0000000000000000
> 0000000000000000 0000000000000000 0000000000000000 : > DUser!DuVisual::xrDrawFull+__ 0x929 > 000000000015f290 000007fefbe790d0 : 0000000000000000
> 0000000000000000 0000000000000001 0000000000000000 : > DUser!DuVisual::xrDrawFull+ __0x97d > 000000000015f440 000007fefbe78ff7 : 0000000000000000
> 0000000014010099 0000000000000000 0000000000000000 : > DUser!DuVisual::xrDrawStart+__ 0x58 > 000000000015f470 000007fefbe78aa7 : 0000000000000001
> 000000000033f090 0000000014010099 000004b000000640 : > DUser!DuRootGadget:: __xrDrawTree+0x51c > 000000000015f650 000007fefbe71859 : 0000000000000000
> 0000000000000000 000004b000000000 0000000000000000 : > DUser!HWndContainer::__ xdHandleMessage+0x2b4 > 000000000015f950 00000000777f8971 : 0000000000000000
> 0000000000000000 0000000000000001 000007fefbe71785 : > DUser!ExtraInfoWndProc+0x8b > 000000000015f9b0 00000000777f72cb : 0000000000000000
> 000007fefbe717e4 0000000000000000 0000000000000000 : > USER32! __UserCallWinProcCheckWow+0x163 > 000000000015fa70 00000000777f6829 : 0000000000000000
> 00000000777f919b 0000000000000000 0000000000000001 : > USER32!DispatchClientMessage+__ 0xc3 > 000000000015fad0 0000000077931225 : 000000000000000f
> 0000000000000000 0000000000000000 0000032000006528 : > USER32!_fnDWORD+0x2d > 000000000015fb30 00000000777f6e5a : 00000000777f6e6c
> 00000000000004ff 0000000000000000 0000000000000000 : > ntdll! __KiUserCallbackDispatcherContin__ ue > 000000000015fbb8 00000000777f6e6c : 00000000000004ff
> 0000000000000000 0000000000000000 0000000000000001 : > USER32!ZwUserDispatchMessage+ __0xa > 000000000015fbc0 000007fefc7b120b : 0000000000000000
> 0000000000000000 000007fefbe717e4 0000000000307320 : > USER32!DispatchMessageWorker+__ 0x55b > 000000000015fc40 000007fefc7bb0fc : 0000000000000000
> 0000000000000001 0000000000000000 0000000000000000 : > authui!CLogonFrame::DoModal+ __0x13d > 000000000015fcc0 000007fefc7bb27f : 00000000002f31b0
> 00000000002e0df0 00000000002db010 00000000002528e6 : > authui!CLogonUI___ CreateThenDoModalThenDestroy+ __0x299 > 000000000015fd20 00000000ff6354ff : 00000000002d22f0
> 00000000002d22f0 0000000000000000 000000000000000b : > authui!CLogonUI::DoModal+0x73 > 000000000015fd50 00000000ff635b06 : 0000000000000000
> 0000000000000000 0000000000000000 00000000ff631178 : > LogonUI!wWinMain+0xfb > 000000000015fdb0 00000000776d652d : 0000000000000000
> 0000000000000000 0000000000000000 0000000000000000 : > LogonUI!__ ParseCommandLineToStringArrayL __ocalAlloc+0x33a > 000000000015fe70 000000007790c521 : 0000000000000000
> 0000000000000000 0000000000000000 0000000000000000 : > kernel32!BaseThreadInitThunk+__ 0xd > 000000000015fea0 0000000000000000 : 0000000000000000
> 0000000000000000 0000000000000000 00000000`00000000 :
> ntdll!RtlUserThreadStart+0x1d
>
>
> STACK_COMMAND: .trap 0xfffff80000ba1d00 ; kb
>
> CHKIMG_EXTENSION: !chkimg -lo 50 -d !nt
> fffff80003090203 - nt!SwapContext_PatchXSave+2
> [01:21]
> fffff800030902e4 - nt!SwapContext_PatchXRstor+2 (+0xe1)
> [09:29]
> fffff800030904a3 -
> nt!EnlightenedSwapContext___PatchXSave+2 (+0x1bf)
> [01:21]
> fffff80003090586 -
> nt!EnlightenedSwapContext___PatchXRstor+2 (+0xe3)
> [09:29]
> 4 errors : !nt (fffff80003090203-fffff80003090586)
>
> MODULE_NAME: memory_corruption
>
> IMAGE_NAME: memory_corruption
>
> FOLLOWUP_NAME: memory_corruption
>
> DEBUG_FLR_IMAGE_TIMESTAMP: 0
>
> MEMORY_CORRUPTOR: ONE_BIT_LARGE
>
> FAILURE_BUCKET_ID: X64_MEMORY_CORRUPTION_ONE_BIT___LARGE
>
> BUCKET_ID: X64_MEMORY_CORRUPTION_ONE_BIT LARGE
>
> Followup: memory_corruption
> ---------
>
> – mkj
>________________________________________
> //
> // Michael K. Jones
> // Stone Hill Consulting, LLC
> // http://www.stonehill.com
> // __
>
> —
> NTDEV is sponsored by OSR
>
> Visit the list at:
> http://www.osronline.com/__ showlists.cfm?list=ntdev
> http:
>
> OSR is HIRING!! See http://www.osr.com/careers
>
> For our schedule of WDF, WDM, debugging and other seminars
> visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page. cfm?name=ListServer
> http:
>
>
>
> –
> – mkj
>
> //
> // Michael K. Jones
> // Stone Hill Consulting, LLC
> // http://www.stonehill.com
> // ____
>
> —
> NTDEV is sponsored by OSR
>
> Visit the list at:
> http://www.osronline.com/__ showlists.cfm?list=ntdev
> http:
>
> OSR is HIRING!! See http://www.osr.com/careers
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page. cfm?name=ListServer
> http:
>
>

–
– mkj

//
// Michael K. Jones
// Stone Hill Consulting, LLC
// http://www.stonehill.com
// _______________________________________________ </http:></http:></http:></http:></mailto:xxxxx></mailto:xxxxx>

Michael_Jones · July 18, 2014, 2:42pm

Having been burned in the (not too distant past) when upgrading to the
latest WinDbg, I’ve been sticking with 6.12.0002.633 AMD64. What
version do folks here generally recommend?

I have to target XP and above, and my host is (currently) Win7 Pro 64
bit. Mostly I use 1394 and Serial; I have the magic USB dongle, but
I’ve never been able to make it work. I don’t get to target Win8 very
much, so I haven’t tried network debugging.

TIA,

–mkj

On 7/18/2014 12:57 PM, Skywing wrote:

This CODE_CORRUPTION bucketization is a false positive. The debugging tools version used to generate this !analyze dump doesn’t understand the (expected) code changes made to the xsave code in context swap during system startup, hence the CHKIMG_EXTENSION: lines. Generally, the tools will flag code mismatches as a priority problem if they are discovered, as overwritten code (e.g. from a stray DMA, etc.) manifests in a number of varied failure patterns.

A more recent debugger version resolves this particular false positive problem.

S (Msft)

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Scott Noone
Sent: Friday, July 18, 2014 9:27 AM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] CODE_CORRUPTION in crash dump

CODE_CORRUPTION is just the Online Crash Analysis bucket ID, so it’s just a guess that !analyze makes. An unhandled exception from the interrupt dispatching code would be highly unusual, so I suspect it’s a reasonable guess in most of these cases. Clearly in yours though it’s really unrelated.

RtlStringCbVPrintfA in an ISR would be a Really Bad Idea. Note that the documentation specifies an IRQL restriction of PASSIVE_LEVEL on that API.

-scott
OSR
@OSRdrivers

“Michael Jones” wrote in message news:xxxxx@ntdev…

Thanks for your response!

The buffer used to format the trace string is on the stack, so not paged memory. The code uses RtlStringCbVPrintfA (and checks the return value), so not a problem with buffer overflow happening.

I’m not too keen on the fact that the buffer is on the stack; however, I don’t believe it’s overflowing the stack. I’ve had that problem in the past (with other drivers), and IIRC it’s a pretty explicit bug check, which I’m not seeing in this case. Isn’t there a guard page after (well, before) the stack?

I will probably change that buffer to not occupy stack space; however, it’s not a trivial change since I believe it was originally written that way in order to avoid traces from multiple threads stepping on each other. So I’m trying to avoid making that sort of change until I get a better handle on the bug I’m currently chasing.

Cheers,

–mkj

On 7/17/2014 6:20 PM, zhang pei wrote:
> you are writting log from the isr. check if you are referencing some
> paged content and if you are writting too much content which over the
> buffer size.
>
>
>
> ===================
> best regards!
> zhang pei
>
>
> Michael Jones ç¼–å†™ï¼š
>>
>> I’m chasing a problem for a client where a driver for one of their
>> cards hangs when the system starts. I am unable to reproduce it with
>> my hardware (naturally). However, I do get this when start my
>> hardware (which is set up for debugging):
>>
>> Assertion: DPC watchdog timeout
>> This is NOT a break in update time
>> This is most likely a BUG in an ISR
>> Perform a stack trace to find the culprit
>> The period will be doubled on continuation
>> Use gh to continue!!
>>
>> nt! ?? ::FNODOBFM::string'+0x4f3a: >> fffff800030e4b75 cd2c int 2Ch
>>
>> I suspect this is happening because the ISR in this driver spews a lot
>> of messages, and the IRQ is shared with lots of other devices, so this
>> driver’s ISR gets called a lot, only to discover the interrupt is not
>> from it’s device.
>>
>> In any event, I did a “gn”, just to see what the BSOD would look like
>> without Windbg hooked up (in case this is what the client is seeing).
>> The analyze -v is below.
>>
>> I get that the bugcheck is INTERRUPT_EXCEPTION_NOT_HANDLED (since I
>> did a “gn” instead of a “gh”). However, I don’t understand the stuff
>> about CODE_CURRUPTION, and the memory corruption stuff at the end of
>> the analyze. Can anyone enlighten me?
>>
>> TIA, --mkj
>>
>>
>>
>> 0: kd> !analyze -v
>>***********
>>
>>
>>
>> * Bugcheck Analysis
>>
>>
>>
>>
>> *********
>>
>> INTERRUPT_EXCEPTION_NOT_HANDLED (3d)
>> Arguments:
>> Arg1: fffff80000ba0600
>> Arg2: 0000000000000000
>> Arg3: 0000000000000000
>> Arg4: fffff800030e4b75
>>
>> Debugging Details:
>> ------------------
>>
>>
>> CONTEXT: fffff80000ba0600 – (.cxr 0xfffff80000ba0600)
>> rax=0000001cbc843b72 rbx=fffff800031ffe80 rcx=0000000000000002
>> rdx=0000000000000000 rsi=fffffa800e7a3b60 rdi=0000000000000001
>> rip=fffff800030e4b75 rsp=fffff80000ba0fe0 rbp=0000000000000001
>> r8=0000000000000000 r9=0000000000000000 r10=0000000000000000
>> r11=fffff80000ba10c0 r12=0000000000000000 r13=000000000000000a
>> r14=0000000000000004 r15=0000000000000001
>> iopl=0 nv up ei pl zr na po nc
>> cs=0010 ss=0018 ds=002b es=002b fs=0053 gs=002b
>> efl=00000246
>> nt! ?? ::FNODOBFM::string'+0x4f3a: >> fffff800030e4b75 cd2c int 2Ch
>> Resetting default scope
>>
>> DEFAULT_BUCKET_ID: CODE_CORRUPTION
>>
>> BUGCHECK_STR: 0x3D
>>
>> PROCESS_NAME: LogonUI.exe
>>
>> CURRENT_IRQL: d
>>
>> EXCEPTION_RECORD: fffff80000ba1c58 – (.exr 0xfffff80000ba1c58)
>> ExceptionAddress: fffff800030854b5 (nt!DebugPrint+0x0000000000000015)
>> ExceptionCode: 80000003 (Break instruction exception)
>> ExceptionFlags: 00000000
>> NumberParameters: 1
>> Parameter[0]: 0000000000000001
>>
>> TRAP_FRAME: fffff80000ba1d00 – (.trap 0xfffff80000ba1d00)
>> NOTE: The trap frame does not contain all registers.
>> Some register values may be zeroed or incorrect.
>> rax=0000000000000001 rbx=0000000000000000 rcx=fffff80000ba1f00
>> rdx=000000000000002f rsi=0000000000000000 rdi=0000000000000000
>> rip=fffff800030854b5 rsp=fffff80000ba1e98 rbp=fffff80000ba27b0
>> r8=0000000000000065 r9=0000000000000003 r10=0000000000000000
>> r11=fffff80000ba1db0 r12=0000000000000000 r13=0000000000000000
>> r14=0000000000000000 r15=0000000000000000
>> iopl=0 nv up ei ng nz ac po cy
>> nt!DebugPrint+0x15:
>> fffff800030854b5 c3 ret >> Resetting default scope >> >> LAST_CONTROL_TRANSFER: from fffff80003097eb7 to fffff800030e4b75 >> >> STACK_TEXT: >> fffff80000ba1e98 fffff800030cd675 : 0000000000000000
>> 0000000000000000 0000000000000000 fffff80000ba27b0 : >> nt!DebugPrint+0x15 >> fffff80000ba1ea0 fffff8000313cd0c : 0000000000000000
>> fffff88002fc6e00 fffff80000ba2588 46464646463d2073 : nt! ?? >> ::FNODOBFM::string’+0xc642
>> fffff80000ba2150 fffff88002fbf40b : fffff88002fc6d90 >> fffff80000ba21c0 0000000000000000 00000000fffffffe :
>> nt!DbgPrint+0x3c
>> fffff80000ba2190 fffff88002fbfbda : fffffa8000000005 >> fffff88000000040 fffff88002fc6e00 0000000000000000 :
>> Acrmgpci!DebugPrint+0xcb
>> [c:\clients\xembedded\src\trunk\acrmgpci\driver\driver.c @ 1630]
>> fffff80000ba2570 fffff88002fbfd65 : 00007fff00000000 >> 0000ff1e00000022 fffffa800dbd4af0 fffffa800dbd4af0 :
>> Acrmgpci!LogIsrCode+0x7a
>> [c:\clients\xembedded\src\trunk\acrmgpci\driver\registry.c @ 665]
>> fffff80000ba25d0 fffff88002fbde70 : fffffa800d6a2a80 >> fffffa800d550120 fffffa800daca020 0000000000000000 :
>> Acrmgpci!RunISRCode+0xd5
>> [c:\clients\xembedded\src\trunk\acrmgpci\driver\registry.c @ 714]
>> fffff80000ba26a0 fffff80003089279 : fffffa800d2d8d80 >> fffffa800d6a2a80 fffffa800d2d8d80 0000000000000000 :
>> Acrmgpci!HandleInterrupt+0x30
>> [c:\clients\xembedded\src\trunk\acrmgpci\driver\driver.c @ 441]
>> fffff80000ba26e0 fffff80003089058 : 000000000000001b >> fffff880011289e5 fffff80000ba28a0 fffff8000300d000 :
>> nt!KiScanInterruptObjectList+0x69
>> fffff80000ba2730 fffff800036066f9 : fffff88000fc6a2c >> 0000000000001000 fffffa800d443ac0 fffffa800d44fa20 :
>> nt!KiChainedDispatch+0x128
>> fffff80000ba28c8 fffff88000fc6a2c : 0000000000001000 >> fffffa800d443ac0 fffffa800d44fa20 fffffa800eadbc60 :
>> hal!KeQueryPerformanceCounter+0x5
>> fffff80000ba28d0 fffff88000fd9c7f : fffffa800d440b20 >> 0000000000000000 fffffa800d4409d0 fffffa800eadbc60 :
>> partmgr!PmWmiCounterIoComplete+0x2c
>> fffff80000ba2900 fffff80003090a91 : fffffa800eadbe0b >> fffffa800d4409d0 fffffa800eadbc60 fffffa800eadbc60 : volmgr! ??
>> ::FNODOBFM::string'+0x2cc >> fffff80000ba2940 fffff88001851bce : 000000000000008b
>> 0000000000000001 fffffa800d2e57d0 0000000000000000 : >> nt!IopfCompleteRequest+0x3b1 >> fffff80000ba2a20 fffff80003090a91 : 0000000000000000
>> 0000000000000000 0000000000000000 0000000000000000 : >> CLASSPNP!TransferPktComplete+0x1ce >> fffff80000ba2aa0 fffff8800110641a : fffffa800d2d8540
>> 0000000000000001 fffffa800db24b80 0000000000000000 : >> nt!IopfCompleteRequest+0x3b1 >> fffff80000ba2b80 fffff88001106242 : fffffa800db24b80
>> ffff008004414bda fffffa800d2d8d01 0000000000000000 : >> ataport!IdeCompleteScsiIrp+0x62 >> fffff80000ba2bb0 fffff88001100e32 : 0000000000000002
>> 0000000000000000 0000000000000004 0000ff1e00000004 : >> ataport!IdeCommonCrbCompletion+0x5a >> fffff80000ba2be0 fffff88001109805 : fffffa800d2f31a0
>> fffffa800db24b80 0000000000000000 0000000000000000 : >> ataport!IdeTranslateCompletedRequest+0x236 >> fffff80000ba2d10 fffff88001109104 : fffffa800d2f31a0
>> 0000000000000000 fffffa800d2f31a0 0000000000000000 : >> ataport!IdeProcessCompletedRequests+0x4d5 >> fffff80000ba2e40 fffff80003098b1c : fffff800031ffe80
>> fffffa800dd25000 fffffa800d2f3050 fffffa800d2f3118 : >> ataport!IdePortCompletionDpc+0x1a8 >> fffff80000ba2f00 fffff80003090165 : 0000000000000000
>> fffffa800e7a3b60 0000000000000000 fffff88001108f5c : >> nt!KiRetireDpcList+0x1bc >> fffff80000ba2fb0 fffff8000308ff7c : fffffa800d2d8d80
>> fffff96000096788 0000000025010101 fffff8800287a2a0 : >> nt!KxRetireDpcList+0x5 >> fffff8800287a1e0 fffff800030d9453 : fffff80003089063
>> fffff800030890cf fffffa800e7a3b60 fffff8800287a2a0 : >> nt!KiDispatchInterruptContinue >> fffff8800287a210 fffff800030890cf : fffffa800e7a3b60
>> fffff8800287a2a0 000000000185000f 00000000003085b0 : >> nt!KiDpcInterruptBypass+0x13 >> fffff8800287a220 000007fefbe71c61 : 000000000015f0a8
>> 000000000033f750 000000000015f030 000007fefbd8560f : >> nt!KiChainedDispatch+0x19f >> 000000000015efe0 000007fefbe78ca9 : 0000000000320980
>> 0000000000000000 0000800200000038 0000000000320a20 : >> DUser!DuVisual::GetLogRect+0x296 >> 000000000015f020 000007fefbe78dab : 0000000000000000
>> 0000000000320980 0000000000000000 0000000000320c00 : >> DUser!DuVisual::xrDrawTrivial+0x31 >> 000000000015f080 000007fefbe78c5d : 0000000000000000
>> 0000000000000000 0000000000000000 0000000000000000 : >> DUser!DuVisual::xrDrawTrivial+0x151 >> 000000000015f0e0 000007fefbe79703 : 0000000000000000
>> 0000000000000000 0000000000000000 0000000000000000 : >> DUser!DuVisual::xrDrawFull+0x929 >> 000000000015f290 000007fefbe790d0 : 0000000000000000
>> 0000000000000000 0000000000000001 0000000000000000 : >> DUser!DuVisual::xrDrawFull+0x97d >> 000000000015f440 000007fefbe78ff7 : 0000000000000000
>> 0000000014010099 0000000000000000 0000000000000000 : >> DUser!DuVisual::xrDrawStart+0x58 >> 000000000015f470 000007fefbe78aa7 : 0000000000000001
>> 000000000033f090 0000000014010099 000004b000000640 : >> DUser!DuRootGadget::xrDrawTree+0x51c >> 000000000015f650 000007fefbe71859 : 0000000000000000
>> 0000000000000000 000004b000000000 0000000000000000 : >> DUser!HWndContainer::xdHandleMessage+0x2b4 >> 000000000015f950 00000000777f8971 : 0000000000000000
>> 0000000000000000 0000000000000001 000007fefbe71785 : >> DUser!ExtraInfoWndProc+0x8b >> 000000000015f9b0 00000000777f72cb : 0000000000000000
>> 000007fefbe717e4 0000000000000000 0000000000000000 : >> USER32!UserCallWinProcCheckWow+0x163 >> 000000000015fa70 00000000777f6829 : 0000000000000000
>> 00000000777f919b 0000000000000000 0000000000000001 : >> USER32!DispatchClientMessage+0xc3 >> 000000000015fad0 0000000077931225 : 000000000000000f
>> 0000000000000000 0000000000000000 0000032000006528 : >> USER32!_fnDWORD+0x2d >> 000000000015fb30 00000000777f6e5a : 00000000777f6e6c
>> 00000000000004ff 0000000000000000 0000000000000000 : >> ntdll!KiUserCallbackDispatcherContinue >> 000000000015fbb8 00000000777f6e6c : 00000000000004ff
>> 0000000000000000 0000000000000000 0000000000000001 : >> USER32!ZwUserDispatchMessage+0xa >> 000000000015fbc0 000007fefc7b120b : 0000000000000000
>> 0000000000000000 000007fefbe717e4 0000000000307320 : >> USER32!DispatchMessageWorker+0x55b >> 000000000015fc40 000007fefc7bb0fc : 0000000000000000
>> 0000000000000001 0000000000000000 0000000000000000 : >> authui!CLogonFrame::DoModal+0x13d >> 000000000015fcc0 000007fefc7bb27f : 00000000002f31b0
>> 00000000002e0df0 00000000002db010 00000000002528e6 : >> authui!CLogonUI_CreateThenDoModalThenDestroy+0x299 >> 000000000015fd20 00000000ff6354ff : 00000000002d22f0
>> 00000000002d22f0 0000000000000000 000000000000000b : >> authui!CLogonUI::DoModal+0x73 >> 000000000015fd50 00000000ff635b06 : 0000000000000000
>> 0000000000000000 0000000000000000 00000000ff631178 : >> LogonUI!wWinMain+0xfb >> 000000000015fdb0 00000000776d652d : 0000000000000000
>> 0000000000000000 0000000000000000 0000000000000000 : >> LogonUI!ParseCommandLineToStringArrayLocalAlloc+0x33a >> 000000000015fe70 000000007790c521 : 0000000000000000
>> 0000000000000000 0000000000000000 0000000000000000 : >> kernel32!BaseThreadInitThunk+0xd >> 000000000015fea0 0000000000000000 : 0000000000000000
>> 0000000000000000 0000000000000000 00000000`00000000 :
>> ntdll!RtlUserThreadStart+0x1d
>>
>>
>> STACK_COMMAND: .trap 0xfffff80000ba1d00 ; kb
>>
>> CHKIMG_EXTENSION: !chkimg -lo 50 -d !nt
>> fffff80003090203 - nt!SwapContext_PatchXSave+2
>> [01:21]
>> fffff800030902e4 - nt!SwapContext_PatchXRstor+2 (+0xe1)
>> [09:29]
>> fffff800030904a3 - nt!EnlightenedSwapContext_PatchXSave+2 (+0x1bf)
>> [01:21]
>> fffff80003090586 - nt!EnlightenedSwapContext_PatchXRstor+2 (+0xe3)
>> [09:29]
>> 4 errors : !nt (fffff80003090203-fffff80003090586)
>>
>> MODULE_NAME: memory_corruption
>>
>> IMAGE_NAME: memory_corruption
>>
>> FOLLOWUP_NAME: memory_corruption
>>
>> DEBUG_FLR_IMAGE_TIMESTAMP: 0
>>
>> MEMORY_CORRUPTOR: ONE_BIT_LARGE
>>
>> FAILURE_BUCKET_ID: X64_MEMORY_CORRUPTION_ONE_BIT_LARGE
>>
>> BUCKET_ID: X64_MEMORY_CORRUPTION_ONE_BIT_LARGE
>>
>> Followup: memory_corruption
>> ---------
>>
>> – mkj
>>
>> //
>> // Michael K. Jones
>> // Stone Hill Consulting, LLC
>> // http://www.stonehill.com
>> //
>>
>> —
>> NTDEV is sponsored by OSR
>>
>> Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev
>>
>> OSR is HIRING!! See http://www.osr.com/careers
>>
>> For our schedule of WDF, WDM, debugging and other seminars visit:
>> http://www.osr.com/seminars
>>
>> To unsubscribe, visit the List Server section of OSR Online at
>> http://www.osronline.com/page.cfm?name=ListServer
>>
>
> –
> – mkj
>
> //
> // Michael K. Jones
> // Stone Hill Consulting, LLC
> // http://www.stonehill.com
> //
>
>
> —
> NTDEV is sponsored by OSR
>
> Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev
>
> OSR is HIRING!! See http://www.osr.com/careers
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
>

–
– mkj

//
// Michael K. Jones
// Stone Hill Consulting, LLC
// http://www.stonehill.com
//

Ken_Johnson · July 18, 2014, 3:16pm

What problems did you encounter on upgrading?

Generally, the older debugger extensions (for the OS) will not work well with new OS’s that did not exist when those debugger extensions were built, because the debugger extensions are inherently tied to the internal implementation details that evolve over time with OS releases.

S (Msft)

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Michael Jones
Sent: Friday, July 18, 2014 11:41 AM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] CODE_CORRUPTION in crash dump

Having been burned in the (not too distant past) when upgrading to the latest WinDbg, I’ve been sticking with 6.12.0002.633 AMD64. What version do folks here generally recommend?

I have to target XP and above, and my host is (currently) Win7 Pro 64 bit. Mostly I use 1394 and Serial; I have the magic USB dongle, but I’ve never been able to make it work. I don’t get to target Win8 very much, so I haven’t tried network debugging.

TIA,

–mkj

On 7/18/2014 12:57 PM, Skywing wrote:

This CODE_CORRUPTION bucketization is a false positive. The debugging tools version used to generate this !analyze dump doesn’t understand the (expected) code changes made to the xsave code in context swap during system startup, hence the CHKIMG_EXTENSION: lines. Generally, the tools will flag code mismatches as a priority problem if they are discovered, as overwritten code (e.g. from a stray DMA, etc.) manifests in a number of varied failure patterns.

A more recent debugger version resolves this particular false positive problem.

S (Msft)

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Scott Noone
Sent: Friday, July 18, 2014 9:27 AM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] CODE_CORRUPTION in crash dump

CODE_CORRUPTION is just the Online Crash Analysis bucket ID, so it’s just a guess that !analyze makes. An unhandled exception from the interrupt dispatching code would be highly unusual, so I suspect it’s a reasonable guess in most of these cases. Clearly in yours though it’s really unrelated.

RtlStringCbVPrintfA in an ISR would be a Really Bad Idea. Note that the documentation specifies an IRQL restriction of PASSIVE_LEVEL on that API.

-scott
OSR
@OSRdrivers

“Michael Jones” wrote in message news:xxxxx@ntdev…

Thanks for your response!

The buffer used to format the trace string is on the stack, so not paged memory. The code uses RtlStringCbVPrintfA (and checks the return value), so not a problem with buffer overflow happening.

I’m not too keen on the fact that the buffer is on the stack; however, I don’t believe it’s overflowing the stack. I’ve had that problem in the past (with other drivers), and IIRC it’s a pretty explicit bug check, which I’m not seeing in this case. Isn’t there a guard page after (well, before) the stack?

I will probably change that buffer to not occupy stack space; however, it’s not a trivial change since I believe it was originally written that way in order to avoid traces from multiple threads stepping on each other. So I’m trying to avoid making that sort of change until I get a better handle on the bug I’m currently chasing.

Cheers,

–mkj

On 7/17/2014 6:20 PM, zhang pei wrote:
> you are writting log from the isr. check if you are referencing some
> paged content and if you are writting too much content which over the
> buffer size.
>
>
>
> ===================
> best regards!
> zhang pei
>
>
> Michael Jones 编写：
>>
>> I’m chasing a problem for a client where a driver for one of their
>> cards hangs when the system starts. I am unable to reproduce it with
>> my hardware (naturally). However, I do get this when start my
>> hardware (which is set up for debugging):
>>
>> Assertion: DPC watchdog timeout
>> This is NOT a break in update time
>> This is most likely a BUG in an ISR
>> Perform a stack trace to find the culprit
>> The period will be doubled on continuation
>> Use gh to continue!!
>>
>> nt! ?? ::FNODOBFM::string'+0x4f3a: >> fffff800030e4b75 cd2c int 2Ch
>>
>> I suspect this is happening because the ISR in this driver spews a
>> lot of messages, and the IRQ is shared with lots of other devices, so
>> this driver’s ISR gets called a lot, only to discover the interrupt
>> is not from it’s device.
>>
>> In any event, I did a “gn”, just to see what the BSOD would look like
>> without Windbg hooked up (in case this is what the client is seeing).
>> The analyze -v is below.
>>
>> I get that the bugcheck is INTERRUPT_EXCEPTION_NOT_HANDLED (since I
>> did a “gn” instead of a “gh”). However, I don’t understand the stuff
>> about CODE_CURRUPTION, and the memory corruption stuff at the end of
>> the analyze. Can anyone enlighten me?
>>
>> TIA, --mkj
>>
>>
>>
>> 0: kd> !analyze -v
>>************
>>
>>
>>
>>
>> * Bugcheck Analysis
>>
>>
>>
>>
>> *
>> *********
>>
>> INTERRUPT_EXCEPTION_NOT_HANDLED (3d)
>> Arguments:
>> Arg1: fffff80000ba0600
>> Arg2: 0000000000000000
>> Arg3: 0000000000000000
>> Arg4: fffff800030e4b75
>>
>> Debugging Details:
>> ------------------
>>
>>
>> CONTEXT: fffff80000ba0600 – (.cxr 0xfffff80000ba0600)
>> rax=0000001cbc843b72 rbx=fffff800031ffe80 rcx=0000000000000002
>> rdx=0000000000000000 rsi=fffffa800e7a3b60 rdi=0000000000000001
>> rip=fffff800030e4b75 rsp=fffff80000ba0fe0 rbp=0000000000000001
>> r8=0000000000000000 r9=0000000000000000 r10=0000000000000000
>> r11=fffff80000ba10c0 r12=0000000000000000 r13=000000000000000a
>> r14=0000000000000004 r15=0000000000000001
>> iopl=0 nv up ei pl zr na po nc
>> cs=0010 ss=0018 ds=002b es=002b fs=0053 gs=002b
>> efl=00000246
>> nt! ?? ::FNODOBFM::string'+0x4f3a: >> fffff800030e4b75 cd2c int 2Ch
>> Resetting default scope
>>
>> DEFAULT_BUCKET_ID: CODE_CORRUPTION
>>
>> BUGCHECK_STR: 0x3D
>>
>> PROCESS_NAME: LogonUI.exe
>>
>> CURRENT_IRQL: d
>>
>> EXCEPTION_RECORD: fffff80000ba1c58 – (.exr 0xfffff80000ba1c58)
>> ExceptionAddress: fffff800030854b5 (nt!DebugPrint+0x0000000000000015)
>> ExceptionCode: 80000003 (Break instruction exception)
>> ExceptionFlags: 00000000
>> NumberParameters: 1
>> Parameter[0]: 0000000000000001
>>
>> TRAP_FRAME: fffff80000ba1d00 – (.trap 0xfffff80000ba1d00)
>> NOTE: The trap frame does not contain all registers.
>> Some register values may be zeroed or incorrect.
>> rax=0000000000000001 rbx=0000000000000000 rcx=fffff80000ba1f00
>> rdx=000000000000002f rsi=0000000000000000 rdi=0000000000000000
>> rip=fffff800030854b5 rsp=fffff80000ba1e98 rbp=fffff80000ba27b0
>> r8=0000000000000065 r9=0000000000000003 r10=0000000000000000
>> r11=fffff80000ba1db0 r12=0000000000000000 r13=0000000000000000
>> r14=0000000000000000 r15=0000000000000000
>> iopl=0 nv up ei ng nz ac po cy
>> nt!DebugPrint+0x15:
>> fffff800030854b5 c3 ret >> Resetting default scope >> >> LAST_CONTROL_TRANSFER: from fffff80003097eb7 to fffff800030e4b75 >> >> STACK_TEXT: >> fffff80000ba1e98 fffff800030cd675 : 0000000000000000
>> 0000000000000000 0000000000000000 fffff80000ba27b0 : >> nt!DebugPrint+0x15 >> fffff80000ba1ea0 fffff8000313cd0c : 0000000000000000
>> fffff88002fc6e00 fffff80000ba2588 46464646463d2073 : nt! ?? >> ::FNODOBFM::string’+0xc642
>> fffff80000ba2150 fffff88002fbf40b : fffff88002fc6d90 >> fffff80000ba21c0 0000000000000000 00000000fffffffe :
>> nt!DbgPrint+0x3c
>> fffff80000ba2190 fffff88002fbfbda : fffffa8000000005 >> fffff88000000040 fffff88002fc6e00 0000000000000000 :
>> Acrmgpci!DebugPrint+0xcb
>> [c:\clients\xembedded\src\trunk\acrmgpci\driver\driver.c @ 1630]
>> fffff80000ba2570 fffff88002fbfd65 : 00007fff00000000 >> 0000ff1e00000022 fffffa800dbd4af0 fffffa800dbd4af0 :
>> Acrmgpci!LogIsrCode+0x7a
>> [c:\clients\xembedded\src\trunk\acrmgpci\driver\registry.c @ 665]
>> fffff80000ba25d0 fffff88002fbde70 : fffffa800d6a2a80 >> fffffa800d550120 fffffa800daca020 0000000000000000 :
>> Acrmgpci!RunISRCode+0xd5
>> [c:\clients\xembedded\src\trunk\acrmgpci\driver\registry.c @ 714]
>> fffff80000ba26a0 fffff80003089279 : fffffa800d2d8d80 >> fffffa800d6a2a80 fffffa800d2d8d80 0000000000000000 :
>> Acrmgpci!HandleInterrupt+0x30
>> [c:\clients\xembedded\src\trunk\acrmgpci\driver\driver.c @ 441]
>> fffff80000ba26e0 fffff80003089058 : 000000000000001b >> fffff880011289e5 fffff80000ba28a0 fffff8000300d000 :
>> nt!KiScanInterruptObjectList+0x69
>> fffff80000ba2730 fffff800036066f9 : fffff88000fc6a2c >> 0000000000001000 fffffa800d443ac0 fffffa800d44fa20 :
>> nt!KiChainedDispatch+0x128
>> fffff80000ba28c8 fffff88000fc6a2c : 0000000000001000 >> fffffa800d443ac0 fffffa800d44fa20 fffffa800eadbc60 :
>> hal!KeQueryPerformanceCounter+0x5
>> fffff80000ba28d0 fffff88000fd9c7f : fffffa800d440b20 >> 0000000000000000 fffffa800d4409d0 fffffa800eadbc60 :
>> partmgr!PmWmiCounterIoComplete+0x2c
>> fffff80000ba2900 fffff80003090a91 : fffffa800eadbe0b >> fffffa800d4409d0 fffffa800eadbc60 fffffa800eadbc60 : volmgr! ??
>> ::FNODOBFM::string'+0x2cc >> fffff80000ba2940 fffff88001851bce : 000000000000008b
>> 0000000000000001 fffffa800d2e57d0 0000000000000000 : >> nt!IopfCompleteRequest+0x3b1 >> fffff80000ba2a20 fffff80003090a91 : 0000000000000000
>> 0000000000000000 0000000000000000 0000000000000000 : >> CLASSPNP!TransferPktComplete+0x1ce >> fffff80000ba2aa0 fffff8800110641a : fffffa800d2d8540
>> 0000000000000001 fffffa800db24b80 0000000000000000 : >> nt!IopfCompleteRequest+0x3b1 >> fffff80000ba2b80 fffff88001106242 : fffffa800db24b80
>> ffff008004414bda fffffa800d2d8d01 0000000000000000 : >> ataport!IdeCompleteScsiIrp+0x62 >> fffff80000ba2bb0 fffff88001100e32 : 0000000000000002
>> 0000000000000000 0000000000000004 0000ff1e00000004 : >> ataport!IdeCommonCrbCompletion+0x5a >> fffff80000ba2be0 fffff88001109805 : fffffa800d2f31a0
>> fffffa800db24b80 0000000000000000 0000000000000000 : >> ataport!IdeTranslateCompletedRequest+0x236 >> fffff80000ba2d10 fffff88001109104 : fffffa800d2f31a0
>> 0000000000000000 fffffa800d2f31a0 0000000000000000 : >> ataport!IdeProcessCompletedRequests+0x4d5 >> fffff80000ba2e40 fffff80003098b1c : fffff800031ffe80
>> fffffa800dd25000 fffffa800d2f3050 fffffa800d2f3118 : >> ataport!IdePortCompletionDpc+0x1a8 >> fffff80000ba2f00 fffff80003090165 : 0000000000000000
>> fffffa800e7a3b60 0000000000000000 fffff88001108f5c : >> nt!KiRetireDpcList+0x1bc >> fffff80000ba2fb0 fffff8000308ff7c : fffffa800d2d8d80
>> fffff96000096788 0000000025010101 fffff8800287a2a0 : >> nt!KxRetireDpcList+0x5 >> fffff8800287a1e0 fffff800030d9453 : fffff80003089063
>> fffff800030890cf fffffa800e7a3b60 fffff8800287a2a0 : >> nt!KiDispatchInterruptContinue >> fffff8800287a210 fffff800030890cf : fffffa800e7a3b60
>> fffff8800287a2a0 000000000185000f 00000000003085b0 : >> nt!KiDpcInterruptBypass+0x13 >> fffff8800287a220 000007fefbe71c61 : 000000000015f0a8
>> 000000000033f750 000000000015f030 000007fefbd8560f : >> nt!KiChainedDispatch+0x19f >> 000000000015efe0 000007fefbe78ca9 : 0000000000320980
>> 0000000000000000 0000800200000038 0000000000320a20 : >> DUser!DuVisual::GetLogRect+0x296 >> 000000000015f020 000007fefbe78dab : 0000000000000000
>> 0000000000320980 0000000000000000 0000000000320c00 : >> DUser!DuVisual::xrDrawTrivial+0x31 >> 000000000015f080 000007fefbe78c5d : 0000000000000000
>> 0000000000000000 0000000000000000 0000000000000000 : >> DUser!DuVisual::xrDrawTrivial+0x151 >> 000000000015f0e0 000007fefbe79703 : 0000000000000000
>> 0000000000000000 0000000000000000 0000000000000000 : >> DUser!DuVisual::xrDrawFull+0x929 >> 000000000015f290 000007fefbe790d0 : 0000000000000000
>> 0000000000000000 0000000000000001 0000000000000000 : >> DUser!DuVisual::xrDrawFull+0x97d >> 000000000015f440 000007fefbe78ff7 : 0000000000000000
>> 0000000014010099 0000000000000000 0000000000000000 : >> DUser!DuVisual::xrDrawStart+0x58 >> 000000000015f470 000007fefbe78aa7 : 0000000000000001
>> 000000000033f090 0000000014010099 000004b000000640 : >> DUser!DuRootGadget::xrDrawTree+0x51c >> 000000000015f650 000007fefbe71859 : 0000000000000000
>> 0000000000000000 000004b000000000 0000000000000000 : >> DUser!HWndContainer::xdHandleMessage+0x2b4 >> 000000000015f950 00000000777f8971 : 0000000000000000
>> 0000000000000000 0000000000000001 000007fefbe71785 : >> DUser!ExtraInfoWndProc+0x8b >> 000000000015f9b0 00000000777f72cb : 0000000000000000
>> 000007fefbe717e4 0000000000000000 0000000000000000 : >> USER32!UserCallWinProcCheckWow+0x163 >> 000000000015fa70 00000000777f6829 : 0000000000000000
>> 00000000777f919b 0000000000000000 0000000000000001 : >> USER32!DispatchClientMessage+0xc3 >> 000000000015fad0 0000000077931225 : 000000000000000f
>> 0000000000000000 0000000000000000 0000032000006528 : >> USER32!_fnDWORD+0x2d >> 000000000015fb30 00000000777f6e5a : 00000000777f6e6c
>> 00000000000004ff 0000000000000000 0000000000000000 : >> ntdll!KiUserCallbackDispatcherContinue >> 000000000015fbb8 00000000777f6e6c : 00000000000004ff
>> 0000000000000000 0000000000000000 0000000000000001 : >> USER32!ZwUserDispatchMessage+0xa >> 000000000015fbc0 000007fefc7b120b : 0000000000000000
>> 0000000000000000 000007fefbe717e4 0000000000307320 : >> USER32!DispatchMessageWorker+0x55b >> 000000000015fc40 000007fefc7bb0fc : 0000000000000000
>> 0000000000000001 0000000000000000 0000000000000000 : >> authui!CLogonFrame::DoModal+0x13d >> 000000000015fcc0 000007fefc7bb27f : 00000000002f31b0
>> 00000000002e0df0 00000000002db010 00000000002528e6 : >> authui!CLogonUI_CreateThenDoModalThenDestroy+0x299 >> 000000000015fd20 00000000ff6354ff : 00000000002d22f0
>> 00000000002d22f0 0000000000000000 000000000000000b : >> authui!CLogonUI::DoModal+0x73 >> 000000000015fd50 00000000ff635b06 : 0000000000000000
>> 0000000000000000 0000000000000000 00000000ff631178 : >> LogonUI!wWinMain+0xfb >> 000000000015fdb0 00000000776d652d : 0000000000000000
>> 0000000000000000 0000000000000000 0000000000000000 : >> LogonUI!ParseCommandLineToStringArrayLocalAlloc+0x33a >> 000000000015fe70 000000007790c521 : 0000000000000000
>> 0000000000000000 0000000000000000 0000000000000000 : >> kernel32!BaseThreadInitThunk+0xd >> 000000000015fea0 0000000000000000 : 0000000000000000
>> 0000000000000000 0000000000000000 00000000`00000000 :
>> ntdll!RtlUserThreadStart+0x1d
>>
>>
>> STACK_COMMAND: .trap 0xfffff80000ba1d00 ; kb
>>
>> CHKIMG_EXTENSION: !chkimg -lo 50 -d !nt
>> fffff80003090203 - nt!SwapContext_PatchXSave+2
>> [01:21]
>> fffff800030902e4 - nt!SwapContext_PatchXRstor+2 (+0xe1)
>> [09:29]
>> fffff800030904a3 - nt!EnlightenedSwapContext_PatchXSave+2 (+0x1bf)
>> [01:21]
>> fffff80003090586 - nt!EnlightenedSwapContext_PatchXRstor+2 (+0xe3)
>> [09:29]
>> 4 errors : !nt (fffff80003090203-fffff80003090586)
>>
>> MODULE_NAME: memory_corruption
>>
>> IMAGE_NAME: memory_corruption
>>
>> FOLLOWUP_NAME: memory_corruption
>>
>> DEBUG_FLR_IMAGE_TIMESTAMP: 0
>>
>> MEMORY_CORRUPTOR: ONE_BIT_LARGE
>>
>> FAILURE_BUCKET_ID: X64_MEMORY_CORRUPTION_ONE_BIT_LARGE
>>
>> BUCKET_ID: X64_MEMORY_CORRUPTION_ONE_BIT_LARGE
>>
>> Followup: memory_corruption
>> ---------
>>
>> – mkj
>>
>> //
>> // Michael K. Jones
>> // Stone Hill Consulting, LLC
>> // http://www.stonehill.com
>> //
>>
>> —
>> NTDEV is sponsored by OSR
>>
>> Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev
>>
>> OSR is HIRING!! See http://www.osr.com/careers
>>
>> For our schedule of WDF, WDM, debugging and other seminars visit:
>> http://www.osr.com/seminars
>>
>> To unsubscribe, visit the List Server section of OSR Online at
>> http://www.osronline.com/page.cfm?name=ListServer
>>
>
> –
> – mkj
>
> //
> // Michael K. Jones
> // Stone Hill Consulting, LLC
> // http://www.stonehill.com
> //
>
>
> —
> NTDEV is sponsored by OSR
>
> Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev
>
> OSR is HIRING!! See http://www.osr.com/careers
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>

–
– mkj

//
// Michael K. Jones
// Stone Hill Consulting, LLC
// http://www.stonehill.com
//

—
NTDEV is sponsored by OSR

Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev

OSR is HIRING!! See http://www.osr.com/careers

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

OSR_Community_User · July 18, 2014, 3:45pm

> It is doc’d as passive level because for example Unicode string formatting

(%wZ) can cause a page fault.

Mark Roddy

Thanks. I missed that aspect entirely. Again, this pushes the idea that
the ISR should just leave piles of bits and less-time-critical and/or
lower-IRQL threads should clean up those bits. Sort of like walking your
dog in many urban areas. Instead of a “pooper scooper” you use a “bitter
litter gitter”.
joe

On Fri, Jul 18, 2014 at 12:46 PM, Michael Jones
> wrote:
>
>> On 7/18/2014 12:26 PM, Scott Noone wrote:
>>
>>> CODE_CORRUPTION is just the Online Crash Analysis bucket ID, so it’s
>>> just a guess that !analyze makes. An unhandled exception from the
>>> interrupt dispatching code would be highly unusual, so I suspect it’s a
>>> reasonable guess in most of these cases. Clearly in yours though it’s
>>> really unrelated.
>>>
>>
>> OK, good to know. I was worried there was some other underlying problem
>> here it was trying to tell me about.
>>
>>
>>
>>> RtlStringCbVPrintfA in an ISR would be a Really Bad Idea. Note that the
>>> documentation specifies an IRQL restriction of PASSIVE_LEVEL on that
>>> API.
>>>
>>
>> That’s VERY interesting; I didn’t think to look it up (I inherited this
>> code). Any idea why it’s doc’ed as PASSIVE_LEVEL >> might help explain other problems I have so far been unable to
>> reproduce>.
>>
>> --mkj
>>
>>
>>
>>> -scott
>>> OSR
>>> @OSRdrivers
>>>
>>> “Michael Jones” wrote in message news:xxxxx@ntdev…
>>>
>>> Thanks for your response!
>>>
>>> The buffer used to format the trace string is on the stack, so not
>>> paged
>>> memory. The code uses RtlStringCbVPrintfA (and checks the return
>>> value), so not a problem with buffer overflow happening.
>>>
>>> I’m not too keen on the fact that the buffer is on the stack; however,
>>> I
>>> don’t believe it’s overflowing the stack. I’ve had that problem in the
>>> past (with other drivers), and IIRC it’s a pretty explicit bug check,
>>> which I’m not seeing in this case. Isn’t there a guard page after
>>> (well, before) the stack?
>>>
>>> I will probably change that buffer to not occupy stack space; however,
>>> it’s not a trivial change since I believe it was originally written
>>> that
>>> way in order to avoid traces from multiple threads stepping on each
>>> other. So I’m trying to avoid making that sort of change until I get a
>>> better handle on the bug I’m currently chasing.
>>>
>>> Cheers,
>>>
>>> --mkj
>>>
>>>
>>> On 7/17/2014 6:20 PM, zhang pei wrote:
>>>
>>>> you are writting log from the isr. check if you are referencing some
>>>> paged content and if you are writting too much content which over the
>>>> buffer size.
>>>>
>>>>
>>>>
>>>> ===================
>>>> best regards!
>>>> zhang pei
>>>>
>>>>
>>>> Michael Jones ç¼–å†™ï¼š
>>>>
>>>> I’m chasing a problem for a client where a driver for one of their
>>>> cards
>>>> hangs when the system starts. I am unable to reproduce it with my
>>>> hardware (naturally). However, I do get this when start my hardware
>>>> (which is set up for debugging):
>>>>
>>>> Assertion: DPC watchdog timeout
>>>> This is NOT a break in update time
>>>> This is most likely a BUG in an ISR
>>>> Perform a stack trace to find the culprit
>>>> The period will be doubled on continuation
>>>> Use gh to continue!!
>>>>
>>>> nt! ?? ::FNODOBFM::string'+0x4f3a: >>>> fffff800030e4b75 cd2c int 2Ch
>>>>
>>>> I suspect this is happening because the ISR in this driver spews a lot
>>>> of messages, and the IRQ is shared with lots of other devices, so this
>>>> driver’s ISR gets called a lot, only to discover the interrupt is not
>>>> from it’s device.
>>>>
>>>> In any event, I did a “gn”, just to see what the BSOD would look like
>>>> without Windbg hooked up (in case this is what the client is seeing).
>>>> The analyze -v is below.
>>>>
>>>> I get that the bugcheck is INTERRUPT_EXCEPTION_NOT_HANDLED (since I
>>>> did
>>>> a “gn” instead of a “gh”). However, I don’t understand the stuff
>>>> about
>>>> CODE_CURRUPTION, and the memory corruption stuff at the end of the
>>>> analyze. Can anyone enlighten me?
>>>>
>>>> TIA, --mkj
>>>>
>>>>
>>>>
>>>> 0: kd> !analyze -v
>>>>*********************
>>>>
>>>>
>>>>
>>>>
>>>> * Bugcheck Analysis
>>>>
>>>>
>>>>
>>>>
>>>> *******************
>>>>
>>>>
>>>> INTERRUPT_EXCEPTION_NOT_HANDLED (3d)
>>>> Arguments:
>>>> Arg1: fffff80000ba0600
>>>> Arg2: 0000000000000000
>>>> Arg3: 0000000000000000
>>>> Arg4: fffff800030e4b75
>>>>
>>>> Debugging Details:
>>>> ------------------
>>>>
>>>>
>>>> CONTEXT: fffff80000ba0600 – (.cxr 0xfffff80000ba0600)
>>>> rax=0000001cbc843b72 rbx=fffff800031ffe80 rcx=0000000000000002
>>>> rdx=0000000000000000 rsi=fffffa800e7a3b60 rdi=0000000000000001
>>>> rip=fffff800030e4b75 rsp=fffff80000ba0fe0 rbp=0000000000000001
>>>> r8=0000000000000000 r9=0000000000000000 r10=0000000000000000
>>>> r11=fffff80000ba10c0 r12=0000000000000000 r13=000000000000000a
>>>> r14=0000000000000004 r15=0000000000000001
>>>> iopl=0 nv up ei pl zr na po nc
>>>> cs=0010 ss=0018 ds=002b es=002b fs=0053 gs=002b
>>>> efl=00000246
>>>> nt! ?? ::FNODOBFM::string'+0x4f3a: >>>> fffff800030e4b75 cd2c int 2Ch
>>>> Resetting default scope
>>>>
>>>> DEFAULT_BUCKET_ID: CODE_CORRUPTION
>>>>
>>>> BUGCHECK_STR: 0x3D
>>>>
>>>> PROCESS_NAME: LogonUI.exe
>>>>
>>>> CURRENT_IRQL: d
>>>>
>>>> EXCEPTION_RECORD: fffff80000ba1c58 – (.exr 0xfffff80000ba1c58)
>>>> ExceptionAddress: fffff800030854b5 (nt!DebugPrint+0x0000000000000015)
>>>> ExceptionCode: 80000003 (Break instruction exception)
>>>> ExceptionFlags: 00000000
>>>> NumberParameters: 1
>>>> Parameter[0]: 0000000000000001
>>>>
>>>> TRAP_FRAME: fffff80000ba1d00 – (.trap 0xfffff80000ba1d00)
>>>> NOTE: The trap frame does not contain all registers.
>>>> Some register values may be zeroed or incorrect.
>>>> rax=0000000000000001 rbx=0000000000000000 rcx=fffff80000ba1f00
>>>> rdx=000000000000002f rsi=0000000000000000 rdi=0000000000000000
>>>> rip=fffff800030854b5 rsp=fffff80000ba1e98 rbp=fffff80000ba27b0
>>>> r8=0000000000000065 r9=0000000000000003 r10=0000000000000000
>>>> r11=fffff80000ba1db0 r12=0000000000000000 r13=0000000000000000
>>>> r14=0000000000000000 r15=0000000000000000
>>>> iopl=0 nv up ei ng nz ac po cy
>>>> nt!DebugPrint+0x15:
>>>> fffff800030854b5 c3 ret >>>> Resetting default scope >>>> >>>> LAST_CONTROL_TRANSFER: from fffff80003097eb7 to fffff800030e4b75 >>>> >>>> STACK_TEXT: >>>> fffff80000ba1e98 fffff800030cd675 : 0000000000000000
>>>> 0000000000000000 0000000000000000 fffff80000ba27b0 : >>>> nt!DebugPrint+0x15 >>>> fffff80000ba1ea0 fffff8000313cd0c : 0000000000000000
>>>> fffff88002fc6e00 fffff80000ba2588 46464646463d2073 : nt! ?? >>>> ::FNODOBFM::string’+0xc642
>>>> fffff80000ba2150 fffff88002fbf40b : fffff88002fc6d90 >>>> fffff80000ba21c0 0000000000000000 00000000fffffffe :
>>>> nt!DbgPrint+0x3c
>>>> fffff80000ba2190 fffff88002fbfbda : fffffa8000000005 >>>> fffff88000000040 fffff88002fc6e00 0000000000000000 :
>>>> Acrmgpci!DebugPrint+0xcb
>>>> [c:\clients\xembedded\src\trunk\acrmgpci\driver\driver.c @ 1630]
>>>> fffff80000ba2570 fffff88002fbfd65 : 00007fff00000000 >>>> 0000ff1e00000022 fffffa800dbd4af0 fffffa800dbd4af0 :
>>>> Acrmgpci!LogIsrCode+0x7a
>>>> [c:\clients\xembedded\src\trunk\acrmgpci\driver\registry.c @ 665]
>>>> fffff80000ba25d0 fffff88002fbde70 : fffffa800d6a2a80 >>>> fffffa800d550120 fffffa800daca020 0000000000000000 :
>>>> Acrmgpci!RunISRCode+0xd5
>>>> [c:\clients\xembedded\src\trunk\acrmgpci\driver\registry.c @ 714]
>>>> fffff80000ba26a0 fffff80003089279 : fffffa800d2d8d80 >>>> fffffa800d6a2a80 fffffa800d2d8d80 0000000000000000 :
>>>> Acrmgpci!HandleInterrupt+0x30
>>>> [c:\clients\xembedded\src\trunk\acrmgpci\driver\driver.c @ 441]
>>>> fffff80000ba26e0 fffff80003089058 : 000000000000001b >>>> fffff880011289e5 fffff80000ba28a0 fffff8000300d000 :
>>>> nt!KiScanInterruptObjectList+0x69
>>>> fffff80000ba2730 fffff800036066f9 : fffff88000fc6a2c >>>> 0000000000001000 fffffa800d443ac0 fffffa800d44fa20 :
>>>> nt!KiChainedDispatch+0x128
>>>> fffff80000ba28c8 fffff88000fc6a2c : 0000000000001000 >>>> fffffa800d443ac0 fffffa800d44fa20 fffffa800eadbc60 :
>>>> hal!KeQueryPerformanceCounter+0x5
>>>> fffff80000ba28d0 fffff88000fd9c7f : fffffa800d440b20 >>>> 0000000000000000 fffffa800d4409d0 fffffa800eadbc60 :
>>>> partmgr!PmWmiCounterIoComplete+0x2c
>>>> fffff80000ba2900 fffff80003090a91 : fffffa800eadbe0b >>>> fffffa800d4409d0 fffffa800eadbc60 fffffa800eadbc60 : volmgr! ??
>>>> ::FNODOBFM::string'+0x2cc >>>> fffff80000ba2940 fffff88001851bce : 000000000000008b
>>>> 0000000000000001 fffffa800d2e57d0 0000000000000000 : >>>> nt!IopfCompleteRequest+0x3b1 >>>> fffff80000ba2a20 fffff80003090a91 : 0000000000000000
>>>> 0000000000000000 0000000000000000 0000000000000000 : >>>> CLASSPNP!TransferPktComplete+0x1ce >>>> fffff80000ba2aa0 fffff8800110641a : fffffa800d2d8540
>>>> 0000000000000001 fffffa800db24b80 0000000000000000 : >>>> nt!IopfCompleteRequest+0x3b1 >>>> fffff80000ba2b80 fffff88001106242 : fffffa800db24b80
>>>> ffff008004414bda fffffa800d2d8d01 0000000000000000 : >>>> ataport!IdeCompleteScsiIrp+0x62 >>>> fffff80000ba2bb0 fffff88001100e32 : 0000000000000002
>>>> 0000000000000000 0000000000000004 0000ff1e00000004 : >>>> ataport!IdeCommonCrbCompletion+0x5a >>>> fffff80000ba2be0 fffff88001109805 : fffffa800d2f31a0
>>>> fffffa800db24b80 0000000000000000 0000000000000000 : >>>> ataport!IdeTranslateCompletedRequest+0x236 >>>> fffff80000ba2d10 fffff88001109104 : fffffa800d2f31a0
>>>> 0000000000000000 fffffa800d2f31a0 0000000000000000 : >>>> ataport!IdeProcessCompletedRequests+0x4d5 >>>> fffff80000ba2e40 fffff80003098b1c : fffff800031ffe80
>>>> fffffa800dd25000 fffffa800d2f3050 fffffa800d2f3118 : >>>> ataport!IdePortCompletionDpc+0x1a8 >>>> fffff80000ba2f00 fffff80003090165 : 0000000000000000
>>>> fffffa800e7a3b60 0000000000000000 fffff88001108f5c : >>>> nt!KiRetireDpcList+0x1bc >>>> fffff80000ba2fb0 fffff8000308ff7c : fffffa800d2d8d80
>>>> fffff96000096788 0000000025010101 fffff8800287a2a0 : >>>> nt!KxRetireDpcList+0x5 >>>> fffff8800287a1e0 fffff800030d9453 : fffff80003089063
>>>> fffff800030890cf fffffa800e7a3b60 fffff8800287a2a0 : >>>> nt!KiDispatchInterruptContinue >>>> fffff8800287a210 fffff800030890cf : fffffa800e7a3b60
>>>> fffff8800287a2a0 000000000185000f 00000000003085b0 : >>>> nt!KiDpcInterruptBypass+0x13 >>>> fffff8800287a220 000007fefbe71c61 : 000000000015f0a8
>>>> 000000000033f750 000000000015f030 000007fefbd8560f : >>>> nt!KiChainedDispatch+0x19f >>>> 000000000015efe0 000007fefbe78ca9 : 0000000000320980
>>>> 0000000000000000 0000800200000038 0000000000320a20 : >>>> DUser!DuVisual::GetLogRect+0x296 >>>> 000000000015f020 000007fefbe78dab : 0000000000000000
>>>> 0000000000320980 0000000000000000 0000000000320c00 : >>>> DUser!DuVisual::xrDrawTrivial+0x31 >>>> 000000000015f080 000007fefbe78c5d : 0000000000000000
>>>> 0000000000000000 0000000000000000 0000000000000000 : >>>> DUser!DuVisual::xrDrawTrivial+0x151 >>>> 000000000015f0e0 000007fefbe79703 : 0000000000000000
>>>> 0000000000000000 0000000000000000 0000000000000000 : >>>> DUser!DuVisual::xrDrawFull+0x929 >>>> 000000000015f290 000007fefbe790d0 : 0000000000000000
>>>> 0000000000000000 0000000000000001 0000000000000000 : >>>> DUser!DuVisual::xrDrawFull+0x97d >>>> 000000000015f440 000007fefbe78ff7 : 0000000000000000
>>>> 0000000014010099 0000000000000000 0000000000000000 : >>>> DUser!DuVisual::xrDrawStart+0x58 >>>> 000000000015f470 000007fefbe78aa7 : 0000000000000001
>>>> 000000000033f090 0000000014010099 000004b000000640 : >>>> DUser!DuRootGadget::xrDrawTree+0x51c >>>> 000000000015f650 000007fefbe71859 : 0000000000000000
>>>> 0000000000000000 000004b000000000 0000000000000000 : >>>> DUser!HWndContainer::xdHandleMessage+0x2b4 >>>> 000000000015f950 00000000777f8971 : 0000000000000000
>>>> 0000000000000000 0000000000000001 000007fefbe71785 : >>>> DUser!ExtraInfoWndProc+0x8b >>>> 000000000015f9b0 00000000777f72cb : 0000000000000000
>>>> 000007fefbe717e4 0000000000000000 0000000000000000 : >>>> USER32!UserCallWinProcCheckWow+0x163 >>>> 000000000015fa70 00000000777f6829 : 0000000000000000
>>>> 00000000777f919b 0000000000000000 0000000000000001 : >>>> USER32!DispatchClientMessage+0xc3 >>>> 000000000015fad0 0000000077931225 : 000000000000000f
>>>> 0000000000000000 0000000000000000 0000032000006528 : >>>> USER32!_fnDWORD+0x2d >>>> 000000000015fb30 00000000777f6e5a : 00000000777f6e6c
>>>> 00000000000004ff 0000000000000000 0000000000000000 : >>>> ntdll!KiUserCallbackDispatcherContinue >>>> 000000000015fbb8 00000000777f6e6c : 00000000000004ff
>>>> 0000000000000000 0000000000000000 0000000000000001 : >>>> USER32!ZwUserDispatchMessage+0xa >>>> 000000000015fbc0 000007fefc7b120b : 0000000000000000
>>>> 0000000000000000 000007fefbe717e4 0000000000307320 : >>>> USER32!DispatchMessageWorker+0x55b >>>> 000000000015fc40 000007fefc7bb0fc : 0000000000000000
>>>> 0000000000000001 0000000000000000 0000000000000000 : >>>> authui!CLogonFrame::DoModal+0x13d >>>> 000000000015fcc0 000007fefc7bb27f : 00000000002f31b0
>>>> 00000000002e0df0 00000000002db010 00000000002528e6 : >>>> authui!CLogonUI_CreateThenDoModalThenDestroy+0x299 >>>> 000000000015fd20 00000000ff6354ff : 00000000002d22f0
>>>> 00000000002d22f0 0000000000000000 000000000000000b : >>>> authui!CLogonUI::DoModal+0x73 >>>> 000000000015fd50 00000000ff635b06 : 0000000000000000
>>>> 0000000000000000 0000000000000000 00000000ff631178 : >>>> LogonUI!wWinMain+0xfb >>>> 000000000015fdb0 00000000776d652d : 0000000000000000
>>>> 0000000000000000 0000000000000000 0000000000000000 : >>>> LogonUI!ParseCommandLineToStringArrayLocalAlloc+0x33a >>>> 000000000015fe70 000000007790c521 : 0000000000000000
>>>> 0000000000000000 0000000000000000 0000000000000000 : >>>> kernel32!BaseThreadInitThunk+0xd >>>> 000000000015fea0 0000000000000000 : 0000000000000000
>>>> 0000000000000000 0000000000000000 00000000`00000000 :
>>>> ntdll!RtlUserThreadStart+0x1d
>>>>
>>>>
>>>> STACK_COMMAND: .trap 0xfffff80000ba1d00 ; kb
>>>>
>>>> CHKIMG_EXTENSION: !chkimg -lo 50 -d !nt
>>>> fffff80003090203 - nt!SwapContext_PatchXSave+2
>>>> [01:21]
>>>> fffff800030902e4 - nt!SwapContext_PatchXRstor+2 (+0xe1)
>>>> [09:29]
>>>> fffff800030904a3 - nt!EnlightenedSwapContext_PatchXSave+2
>>>> (+0x1bf)
>>>> [01:21]
>>>> fffff80003090586 - nt!EnlightenedSwapContext_PatchXRstor+2
>>>> (+0xe3)
>>>> [09:29]
>>>> 4 errors : !nt (fffff80003090203-fffff80003090586)
>>>>
>>>> MODULE_NAME: memory_corruption
>>>>
>>>> IMAGE_NAME: memory_corruption
>>>>
>>>> FOLLOWUP_NAME: memory_corruption
>>>>
>>>> DEBUG_FLR_IMAGE_TIMESTAMP: 0
>>>>
>>>> MEMORY_CORRUPTOR: ONE_BIT_LARGE
>>>>
>>>> FAILURE_BUCKET_ID: X64_MEMORY_CORRUPTION_ONE_BIT_LARGE
>>>>
>>>> BUCKET_ID: X64_MEMORY_CORRUPTION_ONE_BIT_LARGE
>>>>
>>>> Followup: memory_corruption
>>>> ---------
>>>>
>>>> – mkj
>>>>
>>>> //
>>>> // Michael K. Jones
>>>> // Stone Hill Consulting, LLC
>>>> // http://www.stonehill.com
>>>> //
>>>>
>>>> —
>>>> NTDEV is sponsored by OSR
>>>>
>>>> Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev
>>>>
>>>> OSR is HIRING!! See http://www.osr.com/careers
>>>>
>>>> For our schedule of WDF, WDM, debugging and other seminars visit:
>>>> http://www.osr.com/seminars
>>>>
>>>> To unsubscribe, visit the List Server section of OSR Online at
>>>> http://www.osronline.com/page.cfm?name=ListServer
>>>>
>>>>
>>>
>> –
>> – mkj
>>
>> //
>> // Michael K. Jones
>> // Stone Hill Consulting, LLC
>> // http://www.stonehill.com
>> //
>>
>> —
>> NTDEV is sponsored by OSR
>>
>> Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev
>>
>> OSR is HIRING!! See http://www.osr.com/careers
>>
>> For our schedule of WDF, WDM, debugging and other seminars visit:
>> http://www.osr.com/seminars
>>
>> To unsubscribe, visit the List Server section of OSR Online at
>> http://www.osronline.com/page.cfm?name=ListServer
>>
>
> —
> NTDEV is sponsored by OSR
>
> Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev
>
> OSR is HIRING!! See http://www.osr.com/careers
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer

Michael_Jones · July 18, 2014, 4:11pm

It was last November; I posted in the WINDBG newgroup:
http://www.osronline.com/showthread.cfm?link=249979

I did actually get a phone call and email from someone at Microsoft
about this; I just cannot put my (electronic) fingers on it at the
moment. IIRC, it turned out that there was some bug in that version of
Windbg (maybe a certificate or signing issue? Just can’t remember…).

Anyway, sounds like it is time to upgrade. Are people using the latest
and greatest with success? And, is it possible to download just WinDbg,
or do I still need to get the whole kit and just install Windbg?

–mkj

On 7/18/2014 3:15 PM, Skywing wrote:

What problems did you encounter on upgrading?

Generally, the older debugger extensions (for the OS) will not work well with new OS’s that did not exist when those debugger extensions were built, because the debugger extensions are inherently tied to the internal implementation details that evolve over time with OS releases.

S (Msft)

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Michael Jones
Sent: Friday, July 18, 2014 11:41 AM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] CODE_CORRUPTION in crash dump

Having been burned in the (not too distant past) when upgrading to the latest WinDbg, I’ve been sticking with 6.12.0002.633 AMD64. What version do folks here generally recommend?

I have to target XP and above, and my host is (currently) Win7 Pro 64 bit. Mostly I use 1394 and Serial; I have the magic USB dongle, but I’ve never been able to make it work. I don’t get to target Win8 very much, so I haven’t tried network debugging.

TIA,

–mkj

On 7/18/2014 12:57 PM, Skywing wrote:
> This CODE_CORRUPTION bucketization is a false positive. The debugging tools version used to generate this !analyze dump doesn’t understand the (expected) code changes made to the xsave code in context swap during system startup, hence the CHKIMG_EXTENSION: lines. Generally, the tools will flag code mismatches as a priority problem if they are discovered, as overwritten code (e.g. from a stray DMA, etc.) manifests in a number of varied failure patterns.
>
> A more recent debugger version resolves this particular false positive problem.
>
> - S (Msft)
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of Scott Noone
> Sent: Friday, July 18, 2014 9:27 AM
> To: Windows System Software Devs Interest List
> Subject: Re:[ntdev] CODE_CORRUPTION in crash dump
>
> CODE_CORRUPTION is just the Online Crash Analysis bucket ID, so it’s just a guess that !analyze makes. An unhandled exception from the interrupt dispatching code would be highly unusual, so I suspect it’s a reasonable guess in most of these cases. Clearly in yours though it’s really unrelated.
>
> RtlStringCbVPrintfA in an ISR would be a Really Bad Idea. Note that the documentation specifies an IRQL restriction of PASSIVE_LEVEL on that API.
>
> -scott
> OSR
> @OSRdrivers
>
> “Michael Jones” wrote in message news:xxxxx@ntdev…
>
> Thanks for your response!
>
> The buffer used to format the trace string is on the stack, so not paged memory. The code uses RtlStringCbVPrintfA (and checks the return value), so not a problem with buffer overflow happening.
>
> I’m not too keen on the fact that the buffer is on the stack; however, I don’t believe it’s overflowing the stack. I’ve had that problem in the past (with other drivers), and IIRC it’s a pretty explicit bug check, which I’m not seeing in this case. Isn’t there a guard page after (well, before) the stack?
>
> I will probably change that buffer to not occupy stack space; however, it’s not a trivial change since I believe it was originally written that way in order to avoid traces from multiple threads stepping on each other. So I’m trying to avoid making that sort of change until I get a better handle on the bug I’m currently chasing.
>
> Cheers,
>
> --mkj
>
>
> On 7/17/2014 6:20 PM, zhang pei wrote:
>> you are writting log from the isr. check if you are referencing some
>> paged content and if you are writting too much content which over the
>> buffer size.
>>
>>
>>
>> ===================
>> best regards!
>> zhang pei
>>
>>
>> Michael Jones ç¼–å†™ï¼š
>>>
>>> I’m chasing a problem for a client where a driver for one of their
>>> cards hangs when the system starts. I am unable to reproduce it with
>>> my hardware (naturally). However, I do get this when start my
>>> hardware (which is set up for debugging):
>>>
>>> Assertion: DPC watchdog timeout
>>> This is NOT a break in update time
>>> This is most likely a BUG in an ISR
>>> Perform a stack trace to find the culprit
>>> The period will be doubled on continuation
>>> Use gh to continue!!
>>>
>>> nt! ?? ::FNODOBFM::string'+0x4f3a: >>> fffff800030e4b75 cd2c int 2Ch
>>>
>>> I suspect this is happening because the ISR in this driver spews a
>>> lot of messages, and the IRQ is shared with lots of other devices, so
>>> this driver’s ISR gets called a lot, only to discover the interrupt
>>> is not from it’s device.
>>>
>>> In any event, I did a “gn”, just to see what the BSOD would look like
>>> without Windbg hooked up (in case this is what the client is seeing).
>>> The analyze -v is below.
>>>
>>> I get that the bugcheck is INTERRUPT_EXCEPTION_NOT_HANDLED (since I
>>> did a “gn” instead of a “gh”). However, I don’t understand the stuff
>>> about CODE_CURRUPTION, and the memory corruption stuff at the end of
>>> the analyze. Can anyone enlighten me?
>>>
>>> TIA, --mkj
>>>
>>>
>>>
>>> 0: kd> !analyze -v
>>>************
>>>
>>>
>>>
>>>
>>> * Bugcheck Analysis
>>>
>>>
>>>
>>>
>>> *
>>> *********
>>>
>>> INTERRUPT_EXCEPTION_NOT_HANDLED (3d)
>>> Arguments:
>>> Arg1: fffff80000ba0600
>>> Arg2: 0000000000000000
>>> Arg3: 0000000000000000
>>> Arg4: fffff800030e4b75
>>>
>>> Debugging Details:
>>> ------------------
>>>
>>>
>>> CONTEXT: fffff80000ba0600 – (.cxr 0xfffff80000ba0600)
>>> rax=0000001cbc843b72 rbx=fffff800031ffe80 rcx=0000000000000002
>>> rdx=0000000000000000 rsi=fffffa800e7a3b60 rdi=0000000000000001
>>> rip=fffff800030e4b75 rsp=fffff80000ba0fe0 rbp=0000000000000001
>>> r8=0000000000000000 r9=0000000000000000 r10=0000000000000000
>>> r11=fffff80000ba10c0 r12=0000000000000000 r13=000000000000000a
>>> r14=0000000000000004 r15=0000000000000001
>>> iopl=0 nv up ei pl zr na po nc
>>> cs=0010 ss=0018 ds=002b es=002b fs=0053 gs=002b
>>> efl=00000246
>>> nt! ?? ::FNODOBFM::string'+0x4f3a: >>> fffff800030e4b75 cd2c int 2Ch
>>> Resetting default scope
>>>
>>> DEFAULT_BUCKET_ID: CODE_CORRUPTION
>>>
>>> BUGCHECK_STR: 0x3D
>>>
>>> PROCESS_NAME: LogonUI.exe
>>>
>>> CURRENT_IRQL: d
>>>
>>> EXCEPTION_RECORD: fffff80000ba1c58 – (.exr 0xfffff80000ba1c58)
>>> ExceptionAddress: fffff800030854b5 (nt!DebugPrint+0x0000000000000015)
>>> ExceptionCode: 80000003 (Break instruction exception)
>>> ExceptionFlags: 00000000
>>> NumberParameters: 1
>>> Parameter[0]: 0000000000000001
>>>
>>> TRAP_FRAME: fffff80000ba1d00 – (.trap 0xfffff80000ba1d00)
>>> NOTE: The trap frame does not contain all registers.
>>> Some register values may be zeroed or incorrect.
>>> rax=0000000000000001 rbx=0000000000000000 rcx=fffff80000ba1f00
>>> rdx=000000000000002f rsi=0000000000000000 rdi=0000000000000000
>>> rip=fffff800030854b5 rsp=fffff80000ba1e98 rbp=fffff80000ba27b0
>>> r8=0000000000000065 r9=0000000000000003 r10=0000000000000000
>>> r11=fffff80000ba1db0 r12=0000000000000000 r13=0000000000000000
>>> r14=0000000000000000 r15=0000000000000000
>>> iopl=0 nv up ei ng nz ac po cy
>>> nt!DebugPrint+0x15:
>>> fffff800030854b5 c3 ret >>> Resetting default scope >>> >>> LAST_CONTROL_TRANSFER: from fffff80003097eb7 to fffff800030e4b75 >>> >>> STACK_TEXT: >>> fffff80000ba1e98 fffff800030cd675 : 0000000000000000
>>> 0000000000000000 0000000000000000 fffff80000ba27b0 : >>> nt!DebugPrint+0x15 >>> fffff80000ba1ea0 fffff8000313cd0c : 0000000000000000
>>> fffff88002fc6e00 fffff80000ba2588 46464646463d2073 : nt! ?? >>> ::FNODOBFM::string’+0xc642
>>> fffff80000ba2150 fffff88002fbf40b : fffff88002fc6d90 >>> fffff80000ba21c0 0000000000000000 00000000fffffffe :
>>> nt!DbgPrint+0x3c
>>> fffff80000ba2190 fffff88002fbfbda : fffffa8000000005 >>> fffff88000000040 fffff88002fc6e00 0000000000000000 :
>>> Acrmgpci!DebugPrint+0xcb
>>> [c:\clients\xembedded\src\trunk\acrmgpci\driver\driver.c @ 1630]
>>> fffff80000ba2570 fffff88002fbfd65 : 00007fff00000000 >>> 0000ff1e00000022 fffffa800dbd4af0 fffffa800dbd4af0 :
>>> Acrmgpci!LogIsrCode+0x7a
>>> [c:\clients\xembedded\src\trunk\acrmgpci\driver\registry.c @ 665]
>>> fffff80000ba25d0 fffff88002fbde70 : fffffa800d6a2a80 >>> fffffa800d550120 fffffa800daca020 0000000000000000 :
>>> Acrmgpci!RunISRCode+0xd5
>>> [c:\clients\xembedded\src\trunk\acrmgpci\driver\registry.c @ 714]
>>> fffff80000ba26a0 fffff80003089279 : fffffa800d2d8d80 >>> fffffa800d6a2a80 fffffa800d2d8d80 0000000000000000 :
>>> Acrmgpci!HandleInterrupt+0x30
>>> [c:\clients\xembedded\src\trunk\acrmgpci\driver\driver.c @ 441]
>>> fffff80000ba26e0 fffff80003089058 : 000000000000001b >>> fffff880011289e5 fffff80000ba28a0 fffff8000300d000 :
>>> nt!KiScanInterruptObjectList+0x69
>>> fffff80000ba2730 fffff800036066f9 : fffff88000fc6a2c >>> 0000000000001000 fffffa800d443ac0 fffffa800d44fa20 :
>>> nt!KiChainedDispatch+0x128
>>> fffff80000ba28c8 fffff88000fc6a2c : 0000000000001000 >>> fffffa800d443ac0 fffffa800d44fa20 fffffa800eadbc60 :
>>> hal!KeQueryPerformanceCounter+0x5
>>> fffff80000ba28d0 fffff88000fd9c7f : fffffa800d440b20 >>> 0000000000000000 fffffa800d4409d0 fffffa800eadbc60 :
>>> partmgr!PmWmiCounterIoComplete+0x2c
>>> fffff80000ba2900 fffff80003090a91 : fffffa800eadbe0b >>> fffffa800d4409d0 fffffa800eadbc60 fffffa800eadbc60 : volmgr! ??
>>> ::FNODOBFM::string'+0x2cc >>> fffff80000ba2940 fffff88001851bce : 000000000000008b
>>> 0000000000000001 fffffa800d2e57d0 0000000000000000 : >>> nt!IopfCompleteRequest+0x3b1 >>> fffff80000ba2a20 fffff80003090a91 : 0000000000000000
>>> 0000000000000000 0000000000000000 0000000000000000 : >>> CLASSPNP!TransferPktComplete+0x1ce >>> fffff80000ba2aa0 fffff8800110641a : fffffa800d2d8540
>>> 0000000000000001 fffffa800db24b80 0000000000000000 : >>> nt!IopfCompleteRequest+0x3b1 >>> fffff80000ba2b80 fffff88001106242 : fffffa800db24b80
>>> ffff008004414bda fffffa800d2d8d01 0000000000000000 : >>> ataport!IdeCompleteScsiIrp+0x62 >>> fffff80000ba2bb0 fffff88001100e32 : 0000000000000002
>>> 0000000000000000 0000000000000004 0000ff1e00000004 : >>> ataport!IdeCommonCrbCompletion+0x5a >>> fffff80000ba2be0 fffff88001109805 : fffffa800d2f31a0
>>> fffffa800db24b80 0000000000000000 0000000000000000 : >>> ataport!IdeTranslateCompletedRequest+0x236 >>> fffff80000ba2d10 fffff88001109104 : fffffa800d2f31a0
>>> 0000000000000000 fffffa800d2f31a0 0000000000000000 : >>> ataport!IdeProcessCompletedRequests+0x4d5 >>> fffff80000ba2e40 fffff80003098b1c : fffff800031ffe80
>>> fffffa800dd25000 fffffa800d2f3050 fffffa800d2f3118 : >>> ataport!IdePortCompletionDpc+0x1a8 >>> fffff80000ba2f00 fffff80003090165 : 0000000000000000
>>> fffffa800e7a3b60 0000000000000000 fffff88001108f5c : >>> nt!KiRetireDpcList+0x1bc >>> fffff80000ba2fb0 fffff8000308ff7c : fffffa800d2d8d80
>>> fffff96000096788 0000000025010101 fffff8800287a2a0 : >>> nt!KxRetireDpcList+0x5 >>> fffff8800287a1e0 fffff800030d9453 : fffff80003089063
>>> fffff800030890cf fffffa800e7a3b60 fffff8800287a2a0 : >>> nt!KiDispatchInterruptContinue >>> fffff8800287a210 fffff800030890cf : fffffa800e7a3b60
>>> fffff8800287a2a0 000000000185000f 00000000003085b0 : >>> nt!KiDpcInterruptBypass+0x13 >>> fffff8800287a220 000007fefbe71c61 : 000000000015f0a8
>>> 000000000033f750 000000000015f030 000007fefbd8560f : >>> nt!KiChainedDispatch+0x19f >>> 000000000015efe0 000007fefbe78ca9 : 0000000000320980
>>> 0000000000000000 0000800200000038 0000000000320a20 : >>> DUser!DuVisual::GetLogRect+0x296 >>> 000000000015f020 000007fefbe78dab : 0000000000000000
>>> 0000000000320980 0000000000000000 0000000000320c00 : >>> DUser!DuVisual::xrDrawTrivial+0x31 >>> 000000000015f080 000007fefbe78c5d : 0000000000000000
>>> 0000000000000000 0000000000000000 0000000000000000 : >>> DUser!DuVisual::xrDrawTrivial+0x151 >>> 000000000015f0e0 000007fefbe79703 : 0000000000000000
>>> 0000000000000000 0000000000000000 0000000000000000 : >>> DUser!DuVisual::xrDrawFull+0x929 >>> 000000000015f290 000007fefbe790d0 : 0000000000000000
>>> 0000000000000000 0000000000000001 0000000000000000 : >>> DUser!DuVisual::xrDrawFull+0x97d >>> 000000000015f440 000007fefbe78ff7 : 0000000000000000
>>> 0000000014010099 0000000000000000 0000000000000000 : >>> DUser!DuVisual::xrDrawStart+0x58 >>> 000000000015f470 000007fefbe78aa7 : 0000000000000001
>>> 000000000033f090 0000000014010099 000004b000000640 : >>> DUser!DuRootGadget::xrDrawTree+0x51c >>> 000000000015f650 000007fefbe71859 : 0000000000000000
>>> 0000000000000000 000004b000000000 0000000000000000 : >>> DUser!HWndContainer::xdHandleMessage+0x2b4 >>> 000000000015f950 00000000777f8971 : 0000000000000000
>>> 0000000000000000 0000000000000001 000007fefbe71785 : >>> DUser!ExtraInfoWndProc+0x8b >>> 000000000015f9b0 00000000777f72cb : 0000000000000000
>>> 000007fefbe717e4 0000000000000000 0000000000000000 : >>> USER32!UserCallWinProcCheckWow+0x163 >>> 000000000015fa70 00000000777f6829 : 0000000000000000
>>> 00000000777f919b 0000000000000000 0000000000000001 : >>> USER32!DispatchClientMessage+0xc3 >>> 000000000015fad0 0000000077931225 : 000000000000000f
>>> 0000000000000000 0000000000000000 0000032000006528 : >>> USER32!_fnDWORD+0x2d >>> 000000000015fb30 00000000777f6e5a : 00000000777f6e6c
>>> 00000000000004ff 0000000000000000 0000000000000000 : >>> ntdll!KiUserCallbackDispatcherContinue >>> 000000000015fbb8 00000000777f6e6c : 00000000000004ff
>>> 0000000000000000 0000000000000000 0000000000000001 : >>> USER32!ZwUserDispatchMessage+0xa >>> 000000000015fbc0 000007fefc7b120b : 0000000000000000
>>> 0000000000000000 000007fefbe717e4 0000000000307320 : >>> USER32!DispatchMessageWorker+0x55b >>> 000000000015fc40 000007fefc7bb0fc : 0000000000000000
>>> 0000000000000001 0000000000000000 0000000000000000 : >>> authui!CLogonFrame::DoModal+0x13d >>> 000000000015fcc0 000007fefc7bb27f : 00000000002f31b0
>>> 00000000002e0df0 00000000002db010 00000000002528e6 : >>> authui!CLogonUI_CreateThenDoModalThenDestroy+0x299 >>> 000000000015fd20 00000000ff6354ff : 00000000002d22f0
>>> 00000000002d22f0 0000000000000000 000000000000000b : >>> authui!CLogonUI::DoModal+0x73 >>> 000000000015fd50 00000000ff635b06 : 0000000000000000
>>> 0000000000000000 0000000000000000 00000000ff631178 : >>> LogonUI!wWinMain+0xfb >>> 000000000015fdb0 00000000776d652d : 0000000000000000
>>> 0000000000000000 0000000000000000 0000000000000000 : >>> LogonUI!ParseCommandLineToStringArrayLocalAlloc+0x33a >>> 000000000015fe70 000000007790c521 : 0000000000000000
>>> 0000000000000000 0000000000000000 0000000000000000 : >>> kernel32!BaseThreadInitThunk+0xd >>> 000000000015fea0 0000000000000000 : 0000000000000000
>>> 0000000000000000 0000000000000000 00000000`00000000 :
>>> ntdll!RtlUserThreadStart+0x1d
>>>
>>>
>>> STACK_COMMAND: .trap 0xfffff80000ba1d00 ; kb
>>>
>>> CHKIMG_EXTENSION: !chkimg -lo 50 -d !nt
>>> fffff80003090203 - nt!SwapContext_PatchXSave+2
>>> [01:21]
>>> fffff800030902e4 - nt!SwapContext_PatchXRstor+2 (+0xe1)
>>> [09:29]
>>> fffff800030904a3 - nt!EnlightenedSwapContext_PatchXSave+2 (+0x1bf)
>>> [01:21]
>>> fffff80003090586 - nt!EnlightenedSwapContext_PatchXRstor+2 (+0xe3)
>>> [09:29]
>>> 4 errors : !nt (fffff80003090203-fffff80003090586)
>>>
>>> MODULE_NAME: memory_corruption
>>>
>>> IMAGE_NAME: memory_corruption
>>>
>>> FOLLOWUP_NAME: memory_corruption
>>>
>>> DEBUG_FLR_IMAGE_TIMESTAMP: 0
>>>
>>> MEMORY_CORRUPTOR: ONE_BIT_LARGE
>>>
>>> FAILURE_BUCKET_ID: X64_MEMORY_CORRUPTION_ONE_BIT_LARGE
>>>
>>> BUCKET_ID: X64_MEMORY_CORRUPTION_ONE_BIT_LARGE
>>>
>>> Followup: memory_corruption
>>> ---------
>>>
>>> – mkj
>>>
>>> //
>>> // Michael K. Jones
>>> // Stone Hill Consulting, LLC
>>> // http://www.stonehill.com
>>> //
>>>
>>> —
>>> NTDEV is sponsored by OSR
>>>
>>> Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev
>>>
>>> OSR is HIRING!! See http://www.osr.com/careers
>>>
>>> For our schedule of WDF, WDM, debugging and other seminars visit:
>>> http://www.osr.com/seminars
>>>
>>> To unsubscribe, visit the List Server section of OSR Online at
>>> http://www.osronline.com/page.cfm?name=ListServer
>>>
>>
>> –
>> – mkj
>>
>> //
>> // Michael K. Jones
>> // Stone Hill Consulting, LLC
>> // http://www.stonehill.com
>> //
>>
>>
>> —
>> NTDEV is sponsored by OSR
>>
>> Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev
>>
>> OSR is HIRING!! See http://www.osr.com/careers
>>
>> For our schedule of WDF, WDM, debugging and other seminars visit:
>> http://www.osr.com/seminars
>>
>> To unsubscribe, visit the List Server section of OSR Online at
>> http://www.osronline.com/page.cfm?name=ListServer
>>
>
> –
> – mkj
>
> //
> // Michael K. Jones
> // Stone Hill Consulting, LLC
> // http://www.stonehill.com
> //
>
> —
> NTDEV is sponsored by OSR
>
> Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev
>
> OSR is HIRING!! See http://www.osr.com/careers
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
>

–
– mkj

//
// Michael K. Jones
// Stone Hill Consulting, LLC
// http://www.stonehill.com
//