FltMgr.sys pool usage

NTFSD
1

I wrote a file system minifilter for my company, based on the reparse example, which intercepts IRP_MJ_CREATE calls and redirects certain operations. It has been working great for our company’s usage.

However, on one XP 64bit machine, which is heavily used for testing, we noticed a client-server application getting ENOBUFS on its TCP sockets. One of our team analyzed the pool memory using MS poolmon.exe and found that FltMgr.sys was using a lot of pool memory.

It was the number one pool tag:
Tag Bytes Portion Cumulative
FMsl 91816704 0.22298952 0.222989516

FMsl - fltmgr.sys - STREAM_LIST_CTRL structure

He suspects there is a leak in the minifilter I wrote.

So I am wondering, can a leak in the minifilter cause a leak in the FltMgr.sys pool? I have read that FltMgr.sys does some caching on behalf of minifilters, but it is not clear if a leak in my code can cause a leak in the OS FltMgr.sys.

Thanks!
–Tim

2

xxxxx@grammatech.com wrote:

I wrote a file system minifilter for my company, based on the reparse example, which intercepts IRP_MJ_CREATE calls and redirects certain operations. It has been working great for our company’s usage.

However, on one XP 64bit machine, which is heavily used for testing, we noticed a client-server application getting ENOBUFS on its TCP sockets. One of our team analyzed the pool memory using MS poolmon.exe and found that FltMgr.sys was using a lot of pool memory.

Turn verifier on for your driver and try to unload it. This will reveal
what is being leaked.

Pete

It was the number one pool tag:
Tag Bytes Portion Cumulative
FMsl 91816704 0.22298952 0.222989516

FMsl - fltmgr.sys - STREAM_LIST_CTRL structure

He suspects there is a leak in the minifilter I wrote.

So I am wondering, can a leak in the minifilter cause a leak in the FltMgr.sys pool? I have read that FltMgr.sys does some caching on behalf of minifilters, but it is not clear if a leak in my code can cause a leak in the OS FltMgr.sys.

Thanks!
–Tim

NTFSD is sponsored by OSR

For our schedule of debugging and file system seminars
(including our new fs mini-filter seminar) 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

–
Kernel Drivers
Windows File System and Device Driver Consulting
www.KernelDrivers.com
866.263.9295

3

The STREAM_LIST_CTRL structure is filter manager’s stream context and if you leak references to names or stream contexts or stream handle contexts you will leak one of these. On the other hand, if the file system is keeping its SCBs around for a very long time these structures will be around as well.

You should be able to identify the second case (where the file system has a lot of cached SCBs) if there are roughly the same number of tags for the STREAM_LIST_CTRL and the file system’s SCB structure. For example, if you see something like 1045732 FMsl and 1042198 SCBx (where SCBx is the tag for the file systems’ SCB) then it’s probably this case.

The first case is somewhat trickier to figure out, but try to get your hands on some of these STREAM_LIST_CTRL, you can do !fltkd.streamlist

1f and it should print pretty much everything in that STREAM_LIST_CTRL and whatever it is that has a != 0 Count is probably what you're leaking. Of course, some of these structures might not be leaked so you need to be careful.

1: kd> !fltkd.streamlist fffff9800413ee90 1f

STREAM_LIST_CTRL: fffff9800413ee90 [00000211] LinkedToStream File NoHardlinks
Stream ContextCtrl : (fffff9800413ee98)
VolumeLink : [fffff9800412eec0-fffff98004006ec0]
UseCount : 2
ContextLock : (fffff9800413eed8)
StreamContexts : (fffff9800413ef40) Count=1 <--- someone has a stream context!
CONTEXT_LIST_CTRL: fffff9800413ef40
CONTEXT_NODE: fffff98004480f40 [0008] StreamContext PagedPool
ALLOCATE_CONTEXT_NODE: fffff98001356ec0 "FileInfo" [01] LookasideList (size=80)
AttachedObject : fffff9800413ee90
UseCount : 1
TREE_NODE: fffff98004480f70 (k1=fffff980016a4b50, k2=0000000000000000) [00010001] InTree
UserData : fffff98004480fb0
UserDataSize : 80
FilterLink : [fffff98004486f40-fffff9800442ef40]
StreamHandleContexts : (fffff9800413ef48) Count=0
CONTEXT_LIST_CTRL: fffff9800413ef48
**Empty tree**
NameCacheLock : (fffff9800413ef50)
AllNameContextsTemporary : 0x00000000
LastRenameCompleted : 0x0000000000000000
NormalizedNameCache : (fffff9800413efc0) Count=0
NAME_CACHE_LIST_CTRL: fffff9800413efc0 [00000001] Normalized
**Empty tree**
OpenedNameCache : (fffff9800413efe0) Count=0
NAME_CACHE_LIST_CTRL: fffff9800413efe0 [00000002] Opened
**Empty tree**
ShortNameCache : (fffff9800413efd0) Count=0
NAME_CACHE_LIST_CTRL: fffff9800413efd0 [00000003] Short
**Empty tree**

Regards,
Alex.
This posting is provided "AS IS" with no warranties, and confers no rights.
4

Thanks for your replies. I am running verifier, which bugchecks c4.

I knew it would, since the reparse sample I based my code on mentioned the filename buffer replacement method would cause a false positive leak except on Windows7.

I am not clear on how to use verifier to monitor/check for pool leaks. Is one supposed to do this via the verifier’s Display information about the currently-verified drivers -> monitoring global counters functionality?

Unfortunately, my driver loads, does its job, then unloads, and there is not time to run a UI in between to see anything before the unload/bug check.

I am looking at the crash dump file using windbg. Is there any way to get the pool info out of a crash dump or log file? I broke down the null modem cable/debugger setup months ago and no longer work in the same office, so setting it back up again would be a pain (there’s no host computer next to it).

Also, how does one figure out the address to use for !fltkd.streamlist fffff9800413ee90 1f ??

Thanks for your help!

–Tim

Here is the dump:
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************

DRIVER_VERIFIER_DETECTED_VIOLATION (c4)
A device driver attempting to corrupt the system has been caught. This is
because the driver was specified in the registry as being suspect (by the
administrator) and the kernel has enabled substantial checking of this driver.
If the driver attempts to corrupt the system, bugchecks 0xC4, 0xC1 and 0xA will
be among the most commonly seen crashes.
Arguments:
Arg1: 0000000000000062, A driver has forgotten to free its pool allocations prior to unloading.
Arg2: fffffadf3a5ce100, name of the driver having the issue.
Arg3: fffffadf3a5ce060, verifier internal structure with driver information.
Arg4: 0000000000000003, total # of (paged+nonpaged) allocations that weren’t freed.
Type !verifier 3 drivername.sys for info on the allocations
that were leaked that caused the bugcheck.

Debugging Details:

*** WARNING: Unable to verify timestamp for drvhookcsmf_amd64.sys
*** ERROR: Module load completed but symbols could not be loaded for drvhookcsmf_amd64.sys

BUGCHECK_STR: 0xc4_62

VERIFIER_DRIVER_ENTRY: dt nt!_MI_VERIFIER_DRIVER_ENTRY fffffadf3a5ce060
+0x000 Links : _LIST_ENTRY [0xfffff800011dac50 - 0xfffffadf3a5ce140]
+0x010 Loads : 1
+0x014 Unloads : 0
+0x018 BaseName : _UNICODE_STRING “drvhookcsmf_amd64.sys”
+0x028 StartAddress : 0xfffffadf1b4fa000 +0x030 EndAddress : 0xfffffadf1b508000
+0x038 Flags : 1
+0x040 Signature : 0x98761940
+0x050 PoolPageHeaders : _SLIST_HEADER
+0x060 PoolTrackers : _SLIST_HEADER
+0x070 CurrentPagedPoolAllocations : 3
+0x074 CurrentNonPagedPoolAllocations : 0
+0x078 PeakPagedPoolAllocations : 6
+0x07c PeakNonPagedPoolAllocations : 1
+0x080 PagedBytes : 0x1bc
+0x088 NonPagedBytes : 0
+0x090 PeakPagedBytes : 0x3dc
+0x098 PeakNonPagedBytes : 0x94

IMAGE_NAME: drvhookcsmf_amd64.sys

DEBUG_FLR_IMAGE_TIMESTAMP: 4a1182e0

MODULE_NAME: drvhookcsmf_amd64

FAULTING_MODULE: fffffadf1b4fa000 drvhookcsmf_amd64

CUSTOMER_CRASH_COUNT: 1

DEFAULT_BUCKET_ID: DRIVER_FAULT

PROCESS_NAME: services.exe

CURRENT_IRQL: 0

LAST_CONTROL_TRANSFER: from fffff800013e1b23 to fffff8000102e890

STACK_TEXT:
fffffadf1c901698 fffff800013e1b23 : 00000000000000c4 0000000000000062 fffffadf3a5ce100 fffffadf3a5ce060 : nt!KeBugCheckEx
fffffadf1c9016a0 fffff8000135b694 : 0000007ffffffff8 fffffadf388e72e0 fffffadf376dbdf0 0000000000000000 : nt!MiVerifyingDriverUnloading+0x159
fffffadf1c9016e0 fffff8000131dc6c : fffffadf37673570 fffffadf376735a0 fffffadf376735a0 fffffadf376735a0 : nt!MmUnloadSystemImage+0x257
fffffadf1c901750 fffff80001283eb0 : fffffadf37673570 fffffadf376735a0 fffffadf37673550 0000000000000000 : nt!IopDeleteDriver+0x4c
fffffadf1c901790 fffff8000103c2ae : fffffadf37673570 fffffadf1c901a00 fffffadf376735a0 0000000000000000 : nt!ObpRemoveObjectRoutine+0x14f
fffffadf1c901800 fffff8000131e828 : fffffadf376735a0 fffffadf376735a0 0000000000000000 fffffadf37673608 : nt!ObfDereferenceObject+0x83
fffffadf1c901830 fffff8000102e33d : fffffadf388e72e0 0000000000000000 0000000000000000 0000000000000000 : nt!IopUnloadDriver+0x3b7
fffffadf1c901980 fffff8000102e800 : fffff8000131e575 000000000278f0d0 fffffadf1c901cf0 0000000000000000 : nt!KiSystemServiceCopyEnd+0x3
fffffadf1c901b18 fffff8000131e575 : 000000000278f0d0 fffffadf1c901cf0 0000000000000000 0000000000000000 : nt!KiServiceLinkage
fffffadf1c901b20 fffff8000102e33d : fffffadf388e72e0 0000000000a60c50 0000000000000000 0000000000000001 : nt!IopUnloadDriver+0x104
fffffadf1c901c70 0000000077ef1bfa : 0000000000000000 0000000000000000 0000000000000000 0000000000000000 : nt!KiSystemServiceCopyEnd+0x3
000000000278f0a8 0000000000000000 : 0000000000000000 0000000000000000 0000000000000000 0000000000000000 : 0x77ef1bfa

STACK_COMMAND: kb

FOLLOWUP_NAME: MachineOwner

FAILURE_BUCKET_ID: X64_0xc4_62_IMAGE_drvhookcsmf_amd64.sys_DATE_2009_05_18

BUCKET_ID: X64_0xc4_62_IMAGE_drvhookcsmf_amd64.sys_DATE_2009_05_18

Followup: MachineOwner

5

No need for verifier.exe to investigate such a break - windbg is the appropriate tool for this.

Follow the advice from the !analyze text:

Arg4: 0000000000000003, total # of (paged+nonpaged) allocations that weren’t freed.
Type !verifier 3 drivername.sys for info on the allocations
that were leaked that caused the bugcheck.

i.e. run “!verifier 3 drvhookcsmf_amd64.sys”. That will display the address of the 3 leaked pool blocks, their size, pool tags and the address inside your driver where ExAllocatePool was called. Hopefully that will be enough to figure out who is leaking.

If that’s not enough, and you are using Vista or a newer Windows version, “!verifier 0x80 ADDRESS” might be able to find more information about the leaked pool blocks. ADDRESS is one of the three leaked addresses that “!verifier 3” displayed at the first step.

Dan

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@grammatech.com
Sent: Wednesday, October 14, 2009 11:48 AM
To: Windows File Systems Devs Interest List
Subject: RE:[ntfsd] FltMgr.sys pool usage

Thanks for your replies. I am running verifier, which bugchecks c4.

I knew it would, since the reparse sample I based my code on mentioned the filename buffer replacement method would cause a false positive leak except on Windows7.

I am not clear on how to use verifier to monitor/check for pool leaks. Is one supposed to do this via the verifier’s Display information about the currently-verified drivers -> monitoring global counters functionality?

Unfortunately, my driver loads, does its job, then unloads, and there is not time to run a UI in between to see anything before the unload/bug check.

I am looking at the crash dump file using windbg. Is there any way to get the pool info out of a crash dump or log file? I broke down the null modem cable/debugger setup months ago and no longer work in the same office, so setting it back up again would be a pain (there’s no host computer next to it).

Also, how does one figure out the address to use for !fltkd.streamlist fffff9800413ee90 1f ??

Thanks for your help!

–Tim

Here is the dump:
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************

DRIVER_VERIFIER_DETECTED_VIOLATION (c4)
A device driver attempting to corrupt the system has been caught. This is
because the driver was specified in the registry as being suspect (by the
administrator) and the kernel has enabled substantial checking of this driver.
If the driver attempts to corrupt the system, bugchecks 0xC4, 0xC1 and 0xA will
be among the most commonly seen crashes.
Arguments:
Arg1: 0000000000000062, A driver has forgotten to free its pool allocations prior to unloading.
Arg2: fffffadf3a5ce100, name of the driver having the issue.
Arg3: fffffadf3a5ce060, verifier internal structure with driver information.
Arg4: 0000000000000003, total # of (paged+nonpaged) allocations that weren’t freed.
Type !verifier 3 drivername.sys for info on the allocations
that were leaked that caused the bugcheck.

Debugging Details:

*** WARNING: Unable to verify timestamp for drvhookcsmf_amd64.sys
*** ERROR: Module load completed but symbols could not be loaded for drvhookcsmf_amd64.sys

BUGCHECK_STR: 0xc4_62

VERIFIER_DRIVER_ENTRY: dt nt!_MI_VERIFIER_DRIVER_ENTRY fffffadf3a5ce060
+0x000 Links : _LIST_ENTRY [0xfffff800011dac50 - 0xfffffadf3a5ce140]
+0x010 Loads : 1
+0x014 Unloads : 0
+0x018 BaseName : _UNICODE_STRING “drvhookcsmf_amd64.sys”
+0x028 StartAddress : 0xfffffadf1b4fa000 +0x030 EndAddress : 0xfffffadf1b508000
+0x038 Flags : 1
+0x040 Signature : 0x98761940
+0x050 PoolPageHeaders : _SLIST_HEADER
+0x060 PoolTrackers : _SLIST_HEADER
+0x070 CurrentPagedPoolAllocations : 3
+0x074 CurrentNonPagedPoolAllocations : 0
+0x078 PeakPagedPoolAllocations : 6
+0x07c PeakNonPagedPoolAllocations : 1
+0x080 PagedBytes : 0x1bc
+0x088 NonPagedBytes : 0
+0x090 PeakPagedBytes : 0x3dc
+0x098 PeakNonPagedBytes : 0x94

IMAGE_NAME: drvhookcsmf_amd64.sys

DEBUG_FLR_IMAGE_TIMESTAMP: 4a1182e0

MODULE_NAME: drvhookcsmf_amd64

FAULTING_MODULE: fffffadf1b4fa000 drvhookcsmf_amd64

CUSTOMER_CRASH_COUNT: 1

DEFAULT_BUCKET_ID: DRIVER_FAULT

PROCESS_NAME: services.exe

CURRENT_IRQL: 0

LAST_CONTROL_TRANSFER: from fffff800013e1b23 to fffff8000102e890

STACK_TEXT:
fffffadf1c901698 fffff800013e1b23 : 00000000000000c4 0000000000000062 fffffadf3a5ce100 fffffadf3a5ce060 : nt!KeBugCheckEx
fffffadf1c9016a0 fffff8000135b694 : 0000007ffffffff8 fffffadf388e72e0 fffffadf376dbdf0 0000000000000000 : nt!MiVerifyingDriverUnloading+0x159
fffffadf1c9016e0 fffff8000131dc6c : fffffadf37673570 fffffadf376735a0 fffffadf376735a0 fffffadf376735a0 : nt!MmUnloadSystemImage+0x257
fffffadf1c901750 fffff80001283eb0 : fffffadf37673570 fffffadf376735a0 fffffadf37673550 0000000000000000 : nt!IopDeleteDriver+0x4c
fffffadf1c901790 fffff8000103c2ae : fffffadf37673570 fffffadf1c901a00 fffffadf376735a0 0000000000000000 : nt!ObpRemoveObjectRoutine+0x14f
fffffadf1c901800 fffff8000131e828 : fffffadf376735a0 fffffadf376735a0 0000000000000000 fffffadf37673608 : nt!ObfDereferenceObject+0x83
fffffadf1c901830 fffff8000102e33d : fffffadf388e72e0 0000000000000000 0000000000000000 0000000000000000 : nt!IopUnloadDriver+0x3b7
fffffadf1c901980 fffff8000102e800 : fffff8000131e575 000000000278f0d0 fffffadf1c901cf0 0000000000000000 : nt!KiSystemServiceCopyEnd+0x3
fffffadf1c901b18 fffff8000131e575 : 000000000278f0d0 fffffadf1c901cf0 0000000000000000 0000000000000000 : nt!KiServiceLinkage
fffffadf1c901b20 fffff8000102e33d : fffffadf388e72e0 0000000000a60c50 0000000000000000 0000000000000001 : nt!IopUnloadDriver+0x104
fffffadf1c901c70 0000000077ef1bfa : 0000000000000000 0000000000000000 0000000000000000 0000000000000000 : nt!KiSystemServiceCopyEnd+0x3
000000000278f0a8 0000000000000000 : 0000000000000000 0000000000000000 0000000000000000 0000000000000000 : 0x77ef1bfa

STACK_COMMAND: kb

FOLLOWUP_NAME: MachineOwner

FAILURE_BUCKET_ID: X64_0xc4_62_IMAGE_drvhookcsmf_amd64.sys_DATE_2009_05_18

BUCKET_ID: X64_0xc4_62_IMAGE_drvhookcsmf_amd64.sys_DATE_2009_05_18

Followup: MachineOwner

NTFSD is sponsored by OSR

For our schedule of debugging and file system seminars
(including our new fs mini-filter seminar) 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

6

What does “!verifier 3” tell you? You can look at your allocations and
see if any of those that are leaked are “suspicious”. If that doesn’t
work you can go through the alloc/free log (“!verifier 80”).

You might also want to try this out on Windows 7/Server 2008 R2 - sure
it won’t solve your problem, but if it gets rid of false positives, you
can see if there are other leaks you care about.

Tony
OSR

7

I tried “!verifier 3 drvhookcsmk_amd64”, but got the msg: “could not find verifier list” (or something like that). My guess is that this is because I am debugging a crash dump instead of live?

If so, I may have to get out the null modem and and set up a host machine…

Thanks!

8

Verifier data is in crash dumps as well as live systems. Does
“!verifier 3” give you any data at all?

Tony
OSR

9

You need at least a Full or a Kernel dump file. Minidumps are rarely useful - not sure if you tried to use these. Null modem cable and live debugging would be good too.

Other possible problems:

  1. Your kernel symbols are incorrect.
  2. You need a newer kdexts.dll - i.e. a newer Windows package.
  3. An older kdexts.dll might work better if you can reproduce the leak on an x86 OS.

I don’t know which one applies to you. If you show me the output of “version” and “lml”, I might be able to provide more precise ideas.

Dan

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@grammatech.com
Sent: Thursday, October 15, 2009 12:24 PM
To: Windows File Systems Devs Interest List
Subject: RE:[ntfsd] FltMgr.sys pool usage

I tried “!verifier 3 drvhookcsmk_amd64”, but got the msg: “could not find verifier list” (or something like that). My guess is that this is because I am debugging a crash dump instead of live?

If so, I may have to get out the null modem and and set up a host machine…

Thanks!

NTFSD is sponsored by OSR

For our schedule of debugging and file system seminars
(including our new fs mini-filter seminar) 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

10

Yes, I am using the minidump.

Actual output from !verifier 3 is this:

0: kd> !verifier 3 drvhookcsmf_amd64.sys
fffff800011dac80: Unable to get verifier list.

I am using the windows web symbol server for my symbols (as well as my driver’s pdb file).
http://msdl.microsoft.com/download/symbols;
windbg does not really complain about the symbols, except for this:
*** WARNING: Unable to verify checksum for ntkrnlmp.exe
Loading Kernel Symbols
…
…
Loading User Symbols
Loading unloaded module list
…

Output from version:

0: kd> version
Windows Server 2003 Kernel Version 3790 (Service Pack 2) MP (4 procs) Free x64
Product: WinNt, suite: TerminalServer SingleUserTS
Built by: 3790.srv03_sp2_gdr.090319-1204
Machine Name:
Kernel base = 0xfffff80001000000 PsLoadedModuleList = 0xfffff800011d4140
Debug session time: Wed Oct 14 13:51:38.906 2009 (GMT-4)
System Uptime: 0 days 0:10:04.632
64-bit Kernel triage dump: C:\WINDOWS\Minidump\Mini101409-01.dmp

Microsoft (R) Windows Debugger Version 6.11.0001.404 AMD64
Copyright (c) Microsoft Corporation. All rights reserved.

command line: '“C:\Program Files\Debugging Tools for Windows (x64)\windbg.exe” ’ Debugger Process 0xC80
dbgeng: image 6.11.0001.404, built Wed Feb 25 21:10:50 2009
[path: C:\Program Files\Debugging Tools for Windows (x64)\dbgeng.dll]
dbghelp: image 6.11.0001.404, built Wed Feb 25 21:10:27 2009
[path: C:\Program Files\Debugging Tools for Windows (x64)\dbghelp.dll]
DIA version: 11212
Extension DLL search Path:
C:\Program Files\Debugging Tools for Windows (x64)\WINXP;C:\Program Files\Debugging Tools for Windows (x64)\winext;C:\Program Files\Debugging Tools for Windows (x64)\winext\arcade;C:\Program Files\Debugging Tools for Windows (x64)\pri;C:\Program Files\Debugging Tools for Windows (x64);C:\Program Files\Debugging Tools for Windows (x64)\winext\arcade;C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem;C:\cygwin\bin;C:\python26;C:\Program Files\Intel\DMIX;C:\Program Files (x86)\Graphviz2.22\bin;c:\Program Files (x86)\Microsoft SQL Server\90\Tools\binn;C:\WINDOWS\system32\WindowsPowerShell\v1.0
Extension DLL chain:
C:\Program Files\Debugging Tools for Windows (x64)\WINXP\fltkd: image 6.1.7015.0, API 6.0.6, built Wed Feb 25 21:09:12 2009
[path: C:\Program Files\Debugging Tools for Windows (x64)\WINXP\fltkd.dll]
dbghelp: image 6.11.0001.404, API 6.1.6, built Wed Feb 25 21:10:27 2009
[path: C:\Program Files\Debugging Tools for Windows (x64)\dbghelp.dll]
ext: image 6.11.0001.404, API 1.0.0, built Wed Feb 25 21:10:26 2009
[path: C:\Program Files\Debugging Tools for Windows (x64)\winext\ext.dll]
exts: image 6.11.0001.404, API 1.0.0, built Wed Feb 25 21:10:17 2009
[path: C:\Program Files\Debugging Tools for Windows (x64)\WINXP\exts.dll]
kext: image 6.11.0001.404, API 1.0.0, built Wed Feb 25 21:10:18 2009
[path: C:\Program Files\Debugging Tools for Windows (x64)\winext\kext.dll]
kdexts: image 6.1.7015.0, API 1.0.0, built Wed Feb 25 21:09:39 2009
[path: C:\Program Files\Debugging Tools for Windows (x64)\WINXP\kdexts.dll]

output from lml:

0: kd> lml
start end module name
fffff80001000000 fffff80001496000 nt C (pdb symbols) C:\Program Files\Debugging Tools for Windows (x64)\sym\ntkrnlmp.pdb\295F2F2B8EF54B51BEF2AF1556FB67942\ntkrnlmp.pdb
fffffadf1b4fa000 fffffadf1b508000 drvhookcsmf_amd64 (no symbols)
fffffadf1c1e2000 fffffadf1c2a6000 srv (pdb symbols) C:\Program Files\Debugging Tools for Windows (x64)\sym\srv.pdb\4326565F45074861ABD9E37910610E602\srv.pdb

I will enable a full kernel dump and try again. Since this machine is heavily used, I will have to schedule this.

THANKS!

–Tim

11

> Yes, I am using the minidump.

You’re not going to be able to extract anything interesting, the information
just isn’t there in a minidump.

-scott

–
Scott Noone
Consulting Associate
OSR Open Systems Resources, Inc.
http://www.osronline.com

wrote in message news:xxxxx@ntfsd…
> Yes, I am using the minidump.
>
> Actual output from !verifier 3 is this:
>
> 0: kd> !verifier 3 drvhookcsmf_amd64.sys
> fffff800011dac80: Unable to get verifier list.
>
> I am using the windows web symbol server for my symbols (as well as my
> driver’s pdb file).
> http://msdl.microsoft.com/download/symbols;
> windbg does not really complain about the symbols, except for this:
> *** WARNING: Unable to verify checksum for ntkrnlmp.exe
> Loading Kernel Symbols
> …
> …
> Loading User Symbols
> Loading unloaded module list
> …
>
> Output from version:
>
> 0: kd> version
> Windows Server 2003 Kernel Version 3790 (Service Pack 2) MP (4 procs) Free
> x64
> Product: WinNt, suite: TerminalServer SingleUserTS
> Built by: 3790.srv03_sp2_gdr.090319-1204
> Machine Name:
> Kernel base = 0xfffff80001000000 PsLoadedModuleList = 0xfffff800011d4140
> Debug session time: Wed Oct 14 13:51:38.906 2009 (GMT-4)
> System Uptime: 0 days 0:10:04.632
> 64-bit Kernel triage dump: C:\WINDOWS\Minidump\Mini101409-01.dmp
>
> Microsoft (R) Windows Debugger Version 6.11.0001.404 AMD64
> Copyright (c) Microsoft Corporation. All rights reserved.
>
> command line: '“C:\Program Files\Debugging Tools for Windows
> (x64)\windbg.exe” ’ Debugger Process 0xC80
> dbgeng: image 6.11.0001.404, built Wed Feb 25 21:10:50 2009
> [path: C:\Program Files\Debugging Tools for Windows
> (x64)\dbgeng.dll]
> dbghelp: image 6.11.0001.404, built Wed Feb 25 21:10:27 2009
> [path: C:\Program Files\Debugging Tools for Windows
> (x64)\dbghelp.dll]
> DIA version: 11212
> Extension DLL search Path:
> C:\Program Files\Debugging Tools for Windows (x64)\WINXP;C:\Program
> Files\Debugging Tools for Windows (x64)\winext;C:\Program Files\Debugging
> Tools for Windows (x64)\winext\arcade;C:\Program Files\Debugging Tools for
> Windows (x64)\pri;C:\Program Files\Debugging Tools for Windows
> (x64);C:\Program Files\Debugging Tools for Windows
> (x64)\winext\arcade;C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem;C:\cygwin\bin;C:\python26;C:\Program
> Files\Intel\DMIX;C:\Program Files (x86)\Graphviz2.22\bin;c:\Program Files
> (x86)\Microsoft SQL
> Server\90\Tools\binn;C:\WINDOWS\system32\WindowsPowerShell\v1.0
> Extension DLL chain:
> C:\Program Files\Debugging Tools for Windows (x64)\WINXP\fltkd: image
> 6.1.7015.0, API 6.0.6, built Wed Feb 25 21:09:12 2009
> [path: C:\Program Files\Debugging Tools for Windows
> (x64)\WINXP\fltkd.dll]
> dbghelp: image 6.11.0001.404, API 6.1.6, built Wed Feb 25 21:10:27 2009
> [path: C:\Program Files\Debugging Tools for Windows
> (x64)\dbghelp.dll]
> ext: image 6.11.0001.404, API 1.0.0, built Wed Feb 25 21:10:26 2009
> [path: C:\Program Files\Debugging Tools for Windows
> (x64)\winext\ext.dll]
> exts: image 6.11.0001.404, API 1.0.0, built Wed Feb 25 21:10:17 2009
> [path: C:\Program Files\Debugging Tools for Windows
> (x64)\WINXP\exts.dll]
> kext: image 6.11.0001.404, API 1.0.0, built Wed Feb 25 21:10:18 2009
> [path: C:\Program Files\Debugging Tools for Windows
> (x64)\winext\kext.dll]
> kdexts: image 6.1.7015.0, API 1.0.0, built Wed Feb 25 21:09:39 2009
> [path: C:\Program Files\Debugging Tools for Windows
> (x64)\WINXP\kdexts.dll]
>
> output from lml:
>
> 0: kd> lml
> start end module name
> fffff80001000000 fffff80001496000 nt C (pdb symbols)
> C:\Program Files\Debugging Tools for Windows
> (x64)\sym\ntkrnlmp.pdb\295F2F2B8EF54B51BEF2AF1556FB67942\ntkrnlmp.pdb
> fffffadf1b4fa000 fffffadf1b508000 drvhookcsmf_amd64 (no symbols)
> fffffadf1c1e2000 fffffadf1c2a6000 srv (pdb symbols)
> C:\Program Files\Debugging Tools for Windows
> (x64)\sym\srv.pdb\4326565F45074861ABD9E37910610E602\srv.pdb
>
> I will enable a full kernel dump and try again. Since this machine is
> heavily used, I will have to schedule this.
>
> THANKS!
>
> --Tim
>