0x6D with Outlook or FireFox

OSR_Community_User · September 24, 2013, 4:16pm

I am having a system where the usage of Outlook or FireFox causes a 0xD6, and i am stuck … any advice would be appreciated! After having countless minidumps which been not conclusive we switched to kernel dump with verifier flags for special pool and tagging enabled.

bugcheck
Bugcheck code 000000D6
Arguments fffff900c9005000 0000000000000001 fffff96000062384 0000000000000000

!verifier

Verify Level 9 … enabled options are:
Special pool
All pool allocations checked on unload

Summary of All Verifier Statistics

RaiseIrqls 0x0
AcquireSpinLocks 0x1c19127
Synch Executions 0x58e1
Trims 0x0

Pool Allocations Attempted 0x1cc7c3
Pool Allocations Succeeded 0x1cc7c3
Pool Allocations Succeeded SpecialPool 0x1cc7c3
Pool Allocations With NO TAG 0x28
Pool Allocations Failed 0x0
Resource Allocations Failed Deliberately 0x0

Current paged pool allocations 0x58dd for 014ED1E0 bytes
Peak paged pool allocations 0x58e1 for 014ED77C bytes
Current nonpaged pool allocations 0x9b38 for 0375D730 bytes
Peak nonpaged pool allocations 0x9b3c for 03C763F0 bytes

k
Child-SP RetAddr Call Site
fffff8800bc5d9d8 fffff80003158be0 nt!KeBugCheckEx
fffff8800bc5d9e0 fffff800030d8cae nt! ?? ::FNODOBFM::string'+0x4518f fffff8800bc5db40 fffff96000062384 nt!KiPageFault+0x16e fffff8800bc5dcd0 fffff960000622cb win32k!sfac_GetLongGlyphIDs+0x84 fffff8800bc5dd20 fffff960000621fa win32k!sfac_GetWinNTGlyphIDs+0xbb fffff8800bc5dd90 fffff960000620ca win32k!fs_WinNTGetGlyphIDs+0x6a fffff8800bc5dde0 fffff96000061e28 win32k!cjComputeGLYPHSET_MSFT_UNICODE+0x252 fffff8800bc5dea0 fffff9600005917f win32k!bLoadGlyphSet+0xf8 fffff8800bc5ded0 fffff9600005931e win32k!bReloadGlyphSet+0x24b fffff8800bc5e590 fffff96000059276 win32k!ttfdQueryFontTree+0x66 fffff8800bc5e5e0 fffff960000a5fdb win32k!ttfdSemQueryFontTree+0x5a fffff8800bc5e620 fffff960000a5e87 win32k!PDEVOBJ::QueryFontTree+0x63 fffff8800bc5e6a0 fffff9600006007a win32k!PFEOBJ::pfdg+0xa3 fffff8800bc5e700 fffff960000ba74c win32k!RFONTOBJ::bRealizeFont+0x46 fffff8800bc5e820 fffff9600008b071 win32k!RFONTOBJ::bInit+0x548 fffff8800bc5e940 fffff9600008b007 win32k!ulGetFontData2+0x31 fffff8800bc5e9b0 fffff9600008aedd win32k!ulGetFontData+0x7f fffff8800bc5ea00 fffff800030d9e13 win32k!NtGdiGetFontData+0x4d fffff8800bc5ea70 0000000073550b4a nt!KiSystemServiceCopyEnd+0x13 000000000d74e6f8 00000000`00000000 0x73550b4a

!pte fffff900c9005000 returns invalid pool
VA fffff900c9005000
PXE at FFFFF6FB7DBEDF90 PPE at FFFFF6FB7DBF2018 PDE at FFFFF6FB7E403240 PTE at FFFFF6FC80648028
contains 00000001DDDA6863 contains 00000001DC9B3863 contains 000000015BBAC863 contains 0000000200000000
pfn 1ddda6 —DA–KWEV pfn 1dc9b3 —DA–KWEV pfn 15bbac —DA–KWEV not valid
PageFile: 0
Offset: 2
Protect: 0 !pool fffff900c9005000-1000 Pool page fffff900c9004000 region is Special pool Block fffff900c9004000 is a corrupted special pool allocation

!for_each_module s -a @#Base @#End “None”
fffff800031186b8 4e 6f 6e 65 0a 00 90 90-48 4f 54 50 5f 49 44 5f None....HOTP_ID_ fffff80003126e72 4e 6f 6e 65 e9 95 7d 0e-00 90 90 90 90 90 90 90 None…}…
fffff800031bce32 4e 6f 6e 65 e9 c5 10 f3-ff 90 90 90 90 90 90 90 None............ fffff800033e0040 4e 6f 6e 65 00 90 90 90-90 90 90 90 90 90 90 90 None…
fffff800033e194b 4e 6f 6e 65 25 73 0a 00-90 90 90 90 90 90 90 90 None%s.......... fffff8000359d597 4e 6f 6e 65 00 46 73 52-74 6c 4f 70 6c 6f 63 6b None.FsRtlOplock fffff8000359d5ae 4e 6f 6e 65 45 78 00 46-73 52 74 6c 4f 70 6c 6f NoneEx.FsRtlOplo fffff800035b513b 4e 6f 6e 65 00 50 6f 77-65 72 44 65 76 69 63 65 None.PowerDevice
fffff880012d1220 4e 6f 6e 65 00 cc cc cc-cc cc cc cc cc cc cc cc None............ fffff880012d4af7 4e 6f 6e 65 20 3d 20 30-00 53 74 6f 72 50 6f 77 None = 0.StorPow fffff880015c676c 4e 6f 6e 65 00 46 6c 74-4f 70 6c 6f 63 6b 42 72 None.FltOplockBr fffff880015c6781 4e 6f 6e 65 45 78 00 46-6c 74 4f 70 6c 6f 63 6b NoneEx.FltOplock
fffff88002d332d6 4e 6f 6e 65 00 00 00 00-00 00 41 43 4c 5f 44 49 None......ACL_DI fffff8800448a220 4e 6f 6e 65 00 cc cc cc-cc cc cc cc cc cc cc cc None…
fffff8800448daf7 4e 6f 6e 65 20 3d 20 30-00 53 74 6f 72 50 6f 77 None = 0.StorPow fffff88004dbe769 4e 6f 6e 65 00 cc cc 53-74 72 6d 45 76 65 6e 74 None…StrmEvent
fffff88006380847 4e 6f 6e 65 00 00 00 00-00 44 50 5f 56 47 41 5f None.....DP_VGA_ fffff880080509cf 4e 6f 6e 65 00 00 00 00-00 2e 00 69 00 62 00 6c None…i.b.l

I was expecting a nt!ExAllocatePoolWithTag execution is the list above, but only get nt!$$VProc_ImageExportDirectory

0: kd> u fffff8000359d597-1 nt!$$VProc_ImageExportDirectory+0x7596: fffff8000359d596 6f outs dx,dword ptr [rsi]
fffff8000359d597 4e6f outs dx,qword ptr [rsi] fffff8000359d599 6e outs dx,byte ptr [rsi]
fffff8000359d59a 65004673 add byte ptr gs:[rsi+73h],al fffff8000359d59e 52 push rdx
fffff8000359d59f 746c je nt!$$VProc_ImageExportDirectory+0x760d (fffff8000359d60d)
fffff8000359d5a1 4f706c jo nt!$$VProc_ImageExportDirectory+0x7610 (fffff8000359d610)
fffff800`0359d5a4 6f outs dx,dword ptr [rsi]

I am stuck now … how can i find the driver causing it?

OSR_Community_User · September 24, 2013, 5:30pm

What display card are you using? It looks like a potential issue with how
the display is managing fonts. Or, somewhat more likely, some driver you
have not yet set te verifier to watch is tramping through the warehouse
where the bits of fonts are stored. Is the Driver Verifier enabled for
all drivers?

Another possibility is a defective font, defective in a way that isn’t
checked for, but which cause the font engine to become the little engine
that shouldn’t have. Since we see only one example crash here, it’s hard
to tell if there is a consistent pattern. If the crashes are all in the
same function, I might be inclined to suspect a font; if the come from
different places, I’d suspect a driver of drive-by memory damage.

It doesn’t help if you just say “Outlook and FireFox”; it is important to
know what they were doing. Note that fonts downloaded with Web pages are
a potential hazard, if someone has figured out how to create a font that
can crash the font engine, you could be the victim of a subtle DoS attack.
Or merely the victim of a buggy font design program.
joe

I am having a system where the usage of Outlook or FireFox causes a 0xD6,
and i am stuck … any advice would be appreciated! After having countless
minidumps which been not conclusive we switched to kernel dump with
verifier flags for special pool and tagging enabled.

bugcheck
Bugcheck code 000000D6
Arguments fffff900c9005000 0000000000000001 fffff96000062384 0000000000000000

!verifier

Verify Level 9 … enabled options are:
Special pool
All pool allocations checked on unload

Summary of All Verifier Statistics

RaiseIrqls 0x0
AcquireSpinLocks 0x1c19127
Synch Executions 0x58e1
Trims 0x0

Pool Allocations Attempted 0x1cc7c3
Pool Allocations Succeeded 0x1cc7c3
Pool Allocations Succeeded SpecialPool 0x1cc7c3
Pool Allocations With NO TAG 0x28
Pool Allocations Failed 0x0
Resource Allocations Failed Deliberately 0x0

Current paged pool allocations 0x58dd for 014ED1E0 bytes
Peak paged pool allocations 0x58e1 for 014ED77C bytes
Current nonpaged pool allocations 0x9b38 for 0375D730 bytes
Peak nonpaged pool allocations 0x9b3c for 03C763F0 bytes

k
Child-SP RetAddr Call Site
fffff8800bc5d9d8 fffff80003158be0 nt!KeBugCheckEx
fffff8800bc5d9e0 fffff800030d8cae nt! ?? ::FNODOBFM::string'+0x4518f fffff8800bc5db40 fffff96000062384 nt!KiPageFault+0x16e fffff8800bc5dcd0 fffff960000622cb win32k!sfac_GetLongGlyphIDs+0x84 fffff8800bc5dd20 fffff960000621fa win32k!sfac_GetWinNTGlyphIDs+0xbb fffff8800bc5dd90 fffff960000620ca win32k!fs_WinNTGetGlyphIDs+0x6a fffff8800bc5dde0 fffff96000061e28 win32k!cjComputeGLYPHSET_MSFT_UNICODE+0x252 fffff8800bc5dea0 fffff9600005917f win32k!bLoadGlyphSet+0xf8 fffff8800bc5ded0 fffff9600005931e win32k!bReloadGlyphSet+0x24b fffff8800bc5e590 fffff96000059276 win32k!ttfdQueryFontTree+0x66 fffff8800bc5e5e0 fffff960000a5fdb win32k!ttfdSemQueryFontTree+0x5a fffff8800bc5e620 fffff960000a5e87 win32k!PDEVOBJ::QueryFontTree+0x63 fffff8800bc5e6a0 fffff9600006007a win32k!PFEOBJ::pfdg+0xa3 fffff8800bc5e700 fffff960000ba74c win32k!RFONTOBJ::bRealizeFont+0x46 fffff8800bc5e820 fffff9600008b071 win32k!RFONTOBJ::bInit+0x548 fffff8800bc5e940 fffff9600008b007 win32k!ulGetFontData2+0x31 fffff8800bc5e9b0 fffff9600008aedd win32k!ulGetFontData+0x7f fffff8800bc5ea00 fffff800030d9e13 win32k!NtGdiGetFontData+0x4d fffff8800bc5ea70 0000000073550b4a nt!KiSystemServiceCopyEnd+0x13 000000000d74e6f8 00000000`00000000 0x73550b4a

!pte fffff900c9005000 returns invalid pool
VA fffff900c9005000
PXE at FFFFF6FB7DBEDF90 PPE at FFFFF6FB7DBF2018 PDE at
FFFFF6FB7E403240 PTE at FFFFF6FC80648028
contains 00000001DDDA6863 contains 00000001DC9B3863 contains
000000015BBAC863 contains 0000000200000000
pfn 1ddda6 —DA–KWEV pfn 1dc9b3 —DA–KWEV pfn 15bbac
—DA–KWEV not valid
PageFile:

0
Offset:
2
Protect:
0
!pool
fffff900c9005000-1000
Pool
page
fffff900c9004000
region
is
Special
pool
Block
fffff900c9004000
is
a
corrupted
special
pool
allocation

!for_each_module s -a @#Base @#End “None”
fffff800031186b8 4e 6f 6e 65 0a 00 90 90-48 4f 54 50 5f 49 44 5f None....HOTP_ID_ fffff80003126e72 4e 6f 6e 65 e9 95 7d 0e-00 90 90 90 90 90 90 90
None…}…
fffff800031bce32 4e 6f 6e 65 e9 c5 10 f3-ff 90 90 90 90 90 90 90 None............ fffff800033e0040 4e 6f 6e 65 00 90 90 90-90 90 90 90 90 90 90 90
None…
fffff800033e194b 4e 6f 6e 65 25 73 0a 00-90 90 90 90 90 90 90 90 None%s.......... fffff8000359d597 4e 6f 6e 65 00 46 73 52-74 6c 4f 70 6c 6f 63 6b
None.FsRtlOplock fffff8000359d5ae 4e 6f 6e 65 45 78 00 46-73 52 74 6c 4f 70 6c 6f NoneEx.FsRtlOplo fffff800035b513b 4e 6f 6e 65 00 50 6f 77-65
72 44 65 76 69 63 65 None.PowerDevice
fffff880012d1220 4e 6f 6e 65 00 cc cc cc-cc cc cc cc cc cc cc cc None............ fffff880012d4af7 4e 6f 6e 65 20 3d 20 30-00 53 74 6f 72 50 6f 77 None =
0.StorPow fffff880015c676c 4e 6f 6e 65 00 46 6c 74-4f 70 6c 6f 63 6b 42 72 None.FltOplockBr fffff880015c6781 4e 6f 6e 65 45 78 00 46-6c 74 4f 70 6c 6f 63 6b
NoneEx.FltOplock
fffff88002d332d6 4e 6f 6e 65 00 00 00 00-00 00 41 43 4c 5f 44 49 None......ACL_DI fffff8800448a220 4e 6f 6e 65 00 cc cc cc-cc cc cc cc cc cc cc cc
None…
fffff8800448daf7 4e 6f 6e 65 20 3d 20 30-00 53 74 6f 72 50 6f 77 None = 0.StorPow fffff88004dbe769 4e 6f 6e 65 00 cc cc 53-74 72 6d 45 76 65 6e 74
None…StrmEvent
fffff88006380847 4e 6f 6e 65 00 00 00 00-00 44 50 5f 56 47 41 5f None.....DP_VGA_ fffff880080509cf 4e 6f 6e 65 00 00 00 00-00 2e 00 69 00
62 00 6c None…i.b.l

I was expecting a nt!ExAllocatePoolWithTag execution is the list above,
but only get nt!$$VProc_ImageExportDirectory

0: kd> u fffff8000359d597-1 nt!$$VProc_ImageExportDirectory+0x7596: fffff8000359d596 6f outs dx,dword ptr [rsi]
fffff8000359d597 4e6f outs dx,qword ptr [rsi] fffff8000359d599 6e outs dx,byte ptr [rsi]
fffff8000359d59a 65004673 add byte ptr gs:[rsi+73h],al fffff8000359d59e 52 push rdx
fffff8000359d59f 746c je nt!$$VProc_ImageExportDirectory+0x760d (fffff8000359d60d)
fffff8000359d5a1 4f706c jo nt!$$VProc_ImageExportDirectory+0x7610 (fffff8000359d610)
fffff800`0359d5a4 6f outs dx,dword ptr [rsi]

I am stuck now … how can i find the driver causing it?

WINDBG is sponsored by OSR

OSR is hiring!! Info at 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

raj_r · September 25, 2013, 1:11am

this is not an answer to your question but a query

can you tell me what are you doing by searching for a string “NONE” in
all modules
and disassembling one byte off from found address ? why 1 byte
offset ? why are you disassembling seemingly obvious data ?
6F 4E 6F 6E 65 00 46 73 52 74 6C 4F 70 6C 6F oNone.FsRtlOplo

from what i understand in your post the image$$$$ is the nearest
symbol so the symbol is meaningless without unoptimised build and
full private pdb

the third parameter in bugcheck data for D6 if not null is supposed to
indicate the the address which referenced memory

you can try doing db nt!KiBugCheckDriver (might not be much useful in
dump still no harm trying as the doc says it points to drivers name in
unicode string

lkd> !analyze -show d6

DRIVER_PAGE_FAULT_BEYOND_END_OF_ALLOCATION (d6)

N bytes of memory was allocated and more than N bytes are being referenced.
This cannot be protected by try-except.
When possible, the guilty driver’s name (Unicode string) is printed on
the bugcheck screen and saved in KiBugCheckDriver.
Arguments:
Arg1: 00000000, memory referenced
Arg2: 00000000, value 0 = read operation, 1 = write operation
Arg3: 00000000, if non-zero, the address which referenced memory.
Arg4: 00000000, (reserved)

On 9/25/13, xxxxx@flounder.com wrote:
> What display card are you using? It looks like a potential issue with how
> the display is managing fonts. Or, somewhat more likely, some driver you
> have not yet set te verifier to watch is tramping through the warehouse
> where the bits of fonts are stored. Is the Driver Verifier enabled for
> all drivers?
>
> Another possibility is a defective font, defective in a way that isn’t
> checked for, but which cause the font engine to become the little engine
> that shouldn’t have. Since we see only one example crash here, it’s hard
> to tell if there is a consistent pattern. If the crashes are all in the
> same function, I might be inclined to suspect a font; if the come from
> different places, I’d suspect a driver of drive-by memory damage.
>
> It doesn’t help if you just say “Outlook and FireFox”; it is important to
> know what they were doing. Note that fonts downloaded with Web pages are
> a potential hazard, if someone has figured out how to create a font that
> can crash the font engine, you could be the victim of a subtle DoS attack.
> Or merely the victim of a buggy font design program.
> joe
>
>> I am having a system where the usage of Outlook or FireFox causes a 0xD6,
>> and i am stuck … any advice would be appreciated! After having
>> countless
>> minidumps which been not conclusive we switched to kernel dump with
>> verifier flags for special pool and tagging enabled.
>>
>> bugcheck
>> Bugcheck code 000000D6
>> Arguments fffff900c9005000 0000000000000001 fffff96000062384 >> 0000000000000000
>>
>> !verifier
>>
>> Verify Level 9 … enabled options are:
>> Special pool
>> All pool allocations checked on unload
>>
>> Summary of All Verifier Statistics
>>
>> RaiseIrqls 0x0
>> AcquireSpinLocks 0x1c19127
>> Synch Executions 0x58e1
>> Trims 0x0
>>
>> Pool Allocations Attempted 0x1cc7c3
>> Pool Allocations Succeeded 0x1cc7c3
>> Pool Allocations Succeeded SpecialPool 0x1cc7c3
>> Pool Allocations With NO TAG 0x28
>> Pool Allocations Failed 0x0
>> Resource Allocations Failed Deliberately 0x0
>>
>> Current paged pool allocations 0x58dd for 014ED1E0 bytes
>> Peak paged pool allocations 0x58e1 for 014ED77C bytes
>> Current nonpaged pool allocations 0x9b38 for 0375D730 bytes
>> Peak nonpaged pool allocations 0x9b3c for 03C763F0 bytes
>>
>> k
>> Child-SP RetAddr Call Site
>> fffff8800bc5d9d8 fffff80003158be0 nt!KeBugCheckEx
>> fffff8800bc5d9e0 fffff800030d8cae nt! ?? ::FNODOBFM::string'+0x4518f >> fffff8800bc5db40 fffff96000062384 nt!KiPageFault+0x16e >> fffff8800bc5dcd0 fffff960000622cb win32k!sfac_GetLongGlyphIDs+0x84 >> fffff8800bc5dd20 fffff960000621fa win32k!sfac_GetWinNTGlyphIDs+0xbb >> fffff8800bc5dd90 fffff960000620ca win32k!fs_WinNTGetGlyphIDs+0x6a >> fffff8800bc5dde0 fffff96000061e28 >> win32k!cjComputeGLYPHSET_MSFT_UNICODE+0x252 >> fffff8800bc5dea0 fffff9600005917f win32k!bLoadGlyphSet+0xf8 >> fffff8800bc5ded0 fffff9600005931e win32k!bReloadGlyphSet+0x24b >> fffff8800bc5e590 fffff96000059276 win32k!ttfdQueryFontTree+0x66 >> fffff8800bc5e5e0 fffff960000a5fdb win32k!ttfdSemQueryFontTree+0x5a >> fffff8800bc5e620 fffff960000a5e87 win32k!PDEVOBJ::QueryFontTree+0x63 >> fffff8800bc5e6a0 fffff9600006007a win32k!PFEOBJ::pfdg+0xa3 >> fffff8800bc5e700 fffff960000ba74c win32k!RFONTOBJ::bRealizeFont+0x46 >> fffff8800bc5e820 fffff9600008b071 win32k!RFONTOBJ::bInit+0x548 >> fffff8800bc5e940 fffff9600008b007 win32k!ulGetFontData2+0x31 >> fffff8800bc5e9b0 fffff9600008aedd win32k!ulGetFontData+0x7f >> fffff8800bc5ea00 fffff800030d9e13 win32k!NtGdiGetFontData+0x4d >> fffff8800bc5ea70 0000000073550b4a nt!KiSystemServiceCopyEnd+0x13 >> 000000000d74e6f8 0000000000000000 0x73550b4a >> >> !pte fffff900c9005000 returns invalid pool >> VA fffff900c9005000 >> PXE at FFFFF6FB7DBEDF90 PPE at FFFFF6FB7DBF2018 PDE at >> FFFFF6FB7E403240 PTE at FFFFF6FC80648028 >> contains 00000001DDDA6863 contains 00000001DC9B3863 contains >> 000000015BBAC863 contains 0000000200000000 >> pfn 1ddda6 ---DA--KWEV pfn 1dc9b3 ---DA--KWEV pfn 15bbac >> ---DA--KWEV not valid >> >> PageFile: >> >> 0 >> >> Offset: >> 2 >> >> Protect: >> 0 >> !pool >> fffff900c9005000-1000 >> Pool >> page >> fffff900c9004000 >> region >> is >> Special >> pool >> Block >> fffff900c9004000 >> is >> a >> corrupted >> special >> pool >> allocation >> >> >> !for_each_module s -a @#Base @#End "None" >> fffff800031186b8 4e 6f 6e 65 0a 00 90 90-48 4f 54 50 5f 49 44 5f
>> None…HOTP_ID_
>> fffff80003126e72 4e 6f 6e 65 e9 95 7d 0e-00 90 90 90 90 90 90 90 >> None..}......... >> fffff800031bce32 4e 6f 6e 65 e9 c5 10 f3-ff 90 90 90 90 90 90 90
>> None…
>> fffff800033e0040 4e 6f 6e 65 00 90 90 90-90 90 90 90 90 90 90 90 >> None............ >> fffff800033e194b 4e 6f 6e 65 25 73 0a 00-90 90 90 90 90 90 90 90
>> None%s…
>> fffff8000359d597 4e 6f 6e 65 00 46 73 52-74 6c 4f 70 6c 6f 63 6b >> None.FsRtlOplock fffff8000359d5ae 4e 6f 6e 65 45 78 00 46-73 52 74 6c
>> 4f
>> 70 6c 6f NoneEx.FsRtlOplo fffff800035b513b 4e 6f 6e 65 00 50 6f 77-65 >> 72 44 65 76 69 63 65 None.PowerDevice >> fffff880012d1220 4e 6f 6e 65 00 cc cc cc-cc cc cc cc cc cc cc cc
>> None…
>> fffff880012d4af7 4e 6f 6e 65 20 3d 20 30-00 53 74 6f 72 50 6f 77 None >> = >> 0.StorPow fffff880015c676c 4e 6f 6e 65 00 46 6c 74-4f 70 6c 6f 63 6b 42
>> 72 None.FltOplockBr
>> fffff880015c6781 4e 6f 6e 65 45 78 00 46-6c 74 4f 70 6c 6f 63 6b >> NoneEx.FltOplock >> fffff88002d332d6 4e 6f 6e 65 00 00 00 00-00 00 41 43 4c 5f 44 49
>> None…ACL_DI
>> fffff8800448a220 4e 6f 6e 65 00 cc cc cc-cc cc cc cc cc cc cc cc >> None............ >> fffff8800448daf7 4e 6f 6e 65 20 3d 20 30-00 53 74 6f 72 50 6f 77 None
>> =
>> 0.StorPow
>> fffff88004dbe769 4e 6f 6e 65 00 cc cc 53-74 72 6d 45 76 65 6e 74 >> None...StrmEvent >> fffff88006380847 4e 6f 6e 65 00 00 00 00-00 44 50 5f 56 47 41 5f
>> None…DP_VGA_ fffff880080509cf 4e 6f 6e 65 00 00 00 00-00 2e 00 69 >> 00 >> 62 00 6c None.......i.b.l >> >> I was expecting a nt!ExAllocatePoolWithTag execution is the list above, >> but only get nt!$$VProc_ImageExportDirectory >> >> 0: kd> u fffff8000359d597-1
>> nt!$$VProc_ImageExportDirectory+0x7596:
>> fffff8000359d596 6f outs dx,dword ptr [rsi] >> fffff8000359d597 4e6f outs dx,qword ptr [rsi]
>> fffff8000359d599 6e outs dx,byte ptr [rsi] >> fffff8000359d59a 65004673 add byte ptr gs:[rsi+73h],al
>> fffff8000359d59e 52 push rdx >> fffff8000359d59f 746c je
>> nt!$$VProc_ImageExportDirectory+0x760d (fffff8000359d60d) >> fffff8000359d5a1 4f706c jo
>> nt!$$VProc_ImageExportDirectory+0x7610 (fffff8000359d610) >> fffff8000359d5a4 6f outs dx,dword ptr [rsi]
>>
>> I am stuck now … how can i find the driver causing it?
>>
>>
>> —
>> WINDBG is sponsored by OSR
>>
>> OSR is hiring!! Info at 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
>>
>
>
>
> —
> WINDBG is sponsored by OSR
>
> OSR is hiring!! Info at 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
>