NDIS Related System Lock on VMware / Windows 7

NTDEV
1

Hello All,

I’m experiencing a really frustrating problem on Windows 7 that results
in a system lockup. I hope someone with more network driver development
knowledge can provide some insight into what the cause might be.

We have an LWF driver that provides packet filtering and redirection. It
functions without any issue after our software installation process has
completed. However, some very difficult to understand circumstance leads
to an occasional system lockup when run inside of VMware Workstation 6.
It occurs in between calls to adapter bind or adapter unbind operations.
I also tested using real hardware, but have yet to reproduce the issue.
With debugging cranked up, all calls enter and exit our driver without
any indication of an error. I’m also unable to produce this issue using
the same driver binary and a Windows Vista VM.

I’m afraid my kernel debugger knowledge is extremely limited. The only
useful output obtained was using ‘KP’ or “stacktrace with source
arguments” after performing a ‘break’. This consistently shows a call
from NdisIMNotifyPnPEvent to the e1g60i32 Intel miniport driver …

8078adb8 826751ef nt!DbgBreakPointWithStatus+0x4
8078ae14 8267a577 nt!ObfReferenceObjectWithTag+0x65c
*** ERROR: Module load completed but symbols could not be loaded for
i8042prt.sys
8078ae38 8b2e7133 nt!KeUpdateSystemTime+0x13
8078ae9c 8264941d i8042prt+0x1133
*** ERROR: Module load completed but symbols could not be loaded for
E1G60I32.sys
8078aec0 8b37b837 nt!KeSynchronizeExecution+0x3d
*** ERROR: Symbol file could not be found. Defaulted to export symbols
for ndis.sys -
8078aee4 86c6f309 E1G60I32+0x837
8078af20 86c1a9f4 ndis!NdisIMNotifyPnPEvent+0x4c11
8078af48 826723b5 ndis!NdisDprReleaseReadWriteLock+0xca
8078afa4 82672218 nt!KiDispatchInterrupt+0xa05
8078aff4 826719dc nt!KiDispatchInterrupt+0x868
*** ERROR: Symbol file could not be found. Defaulted to export symbols
for halmacpi.dll -
807dfc94 82a1fb29 nt!KiDispatchInterrupt+0x2c
807dfcac 82a1fba9 hal!KeRaiseIrqlToSynchLevel+0x8f
807dfcbc 86c506c7 hal!KfLowerIrql+0x61
807dfd00 82677f2b ndis!NdisWritePciSlotInformation+0x386
807dfd50 8281866d nt!KeInsertQueueDpc+0x382
807dfd90 826ca0d9 nt!PsCreateSystemThread+0x19a
00000000 00000000 nt!wcsupr+0x13a

The stack trace is pretty much identical for freezes that occur during
either software installation or removal ( installs or uninstalls the LWF
driver ). I’m just not familiar enough with network driver related call
stacks to infer what could be causing this issue. I assume our driver is
antagonizing the Intel driver in some way.

I know the information I have to share is pretty lean, but does anyone
have a suggestion? I’m totally stumped.

Thanks in advance,

-Matthew

2

Fix your symbols first.

…symfix
…reload /f

And then

kb

To get a sane stack

d

Sent from my phone with no t9, all spilling mistakes are not intentional.

-----Original Message-----
From: Matthew Grooms
Sent: Monday, November 16, 2009 10:32 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] NDIS Related System Lock on VMware / Windows 7

Hello All,

I’m experiencing a really frustrating problem on Windows 7 that results
in a system lockup. I hope someone with more network driver development
knowledge can provide some insight into what the cause might be.

We have an LWF driver that provides packet filtering and redirection. It
functions without any issue after our software installation process has
completed. However, some very difficult to understand circumstance leads
to an occasional system lockup when run inside of VMware Workstation 6.
It occurs in between calls to adapter bind or adapter unbind operations.
I also tested using real hardware, but have yet to reproduce the issue.
With debugging cranked up, all calls enter and exit our driver without
any indication of an error. I’m also unable to produce this issue using
the same driver binary and a Windows Vista VM.

I’m afraid my kernel debugger knowledge is extremely limited. The only
useful output obtained was using ‘KP’ or “stacktrace with source
arguments” after performing a ‘break’. This consistently shows a call
from NdisIMNotifyPnPEvent to the e1g60i32 Intel miniport driver …

8078adb8 826751ef nt!DbgBreakPointWithStatus+0x4
8078ae14 8267a577 nt!ObfReferenceObjectWithTag+0x65c
ERROR: Module load completed but symbols could not be loaded for
i8042prt.sys
8078ae38 8b2e7133 nt!KeUpdateSystemTime+0x13
8078ae9c 8264941d i8042prt+0x1133
 ERROR: Module load completed but symbols could not be loaded for
E1G60I32.sys
8078aec0 8b37b837 nt!KeSynchronizeExecution+0x3d
ERROR: Symbol file could not be found. Defaulted to export symbols
for ndis.sys -
8078aee4 86c6f309 E1G60I32+0x837
8078af20 86c1a9f4 ndis!NdisIMNotifyPnPEvent+0x4c11
8078af48 826723b5 ndis!NdisDprReleaseReadWriteLock+0xca
8078afa4 82672218 nt!KiDispatchInterrupt+0xa05
8078aff4 826719dc nt!KiDispatchInterrupt+0x868
 ERROR: Symbol file could not be found. Defaulted to export symbols
for halmacpi.dll -
807dfc94 82a1fb29 nt!KiDispatchInterrupt+0x2c
807dfcac 82a1fba9 hal!KeRaiseIrqlToSynchLevel+0x8f
807dfcbc 86c506c7 hal!KfLowerIrql+0x61
807dfd00 82677f2b ndis!NdisWritePciSlotInformation+0x386
807dfd50 8281866d nt!KeInsertQueueDpc+0x382
807dfd90 826ca0d9 nt!PsCreateSystemThread+0x19a
00000000 00000000 nt!wcsupr+0x13a

The stack trace is pretty much identical for freezes that occur during
either software installation or removal ( installs or uninstalls the LWF
driver ). I’m just not familiar enough with network driver related call
stacks to infer what could be causing this issue. I assume our driver is
antagonizing the Intel driver in some way.

I know the information I have to share is pretty lean, but does anyone
have a suggestion? I’m totally stumped.

Thanks in advance,

-Matthew

—
NTDEV is sponsored by OSR

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

3

Doron Holan wrote:

Fix your symbols first.

…symfix
…reload /f

And then

kb

To get a sane stack

Sent from my phone with no t9, all spilling mistakes are not intentional.

Thanks for the suggestion. Does this look more sane?

8078ad88 826a438f 00000001 826a4361 00000000
nt!RtlpBreakWithStatusInstruction
8078ad90 826a4361 00000000 00000000 0002625a nt!KdCheckForDebugBreak+0x22
8078adc0 826a41ef 8af7b72c 84efa008 00000000 nt!KeUpdateRunTime+0x164
8078ae1c 826a9577 8078ae02 8078ae02 000000d1 nt!KeUpdateSystemTime+0x613
8078ae1c 8af7b72c 8078ae02 8078ae02 000000d1
nt!KeUpdateSystemTimeAssist+0x13
8078aecc 8af7a77e 84efa008 853aaac0 00000000
E1G60I32!RxProcessReceiveInterrupts+0x40
8078aee4 86c73309 01efa008 00000000 8078af10
E1G60I32!E1000HandleInterrupt+0x80
8078af20 86c1e9f4 853aaad4 003aaac0 00000000 ndis!ndisMiniportDpc+0xe2
8078af48 826a13b5 853aaad4 853aaac0 00000000 ndis!ndisInterruptDpc+0xaf
8078afa4 826a1218 82762d20 85993548 00000000 nt!KiExecuteAllDpcs+0xf9
8078aff4 826a09dc 8a5bfc78 00000000 00000000 nt!KiRetireDpcList+0xd5
8078aff8 8a5bfc78 00000000 00000000 00000000 nt!KiDispatchInterrupt+0x2c

-Matthew

-----Original Message-----
From: Matthew Grooms
> Sent: Monday, November 16, 2009 10:32 PM
> To: Windows System Software Devs Interest List
> Subject: [ntdev] NDIS Related System Lock on VMware / Windows 7
>
>
> Hello All,
>
> I’m experiencing a really frustrating problem on Windows 7 that results
> in a system lockup. I hope someone with more network driver development
> knowledge can provide some insight into what the cause might be.
>
> We have an LWF driver that provides packet filtering and redirection. It
> functions without any issue after our software installation process has
> completed. However, some very difficult to understand circumstance leads
> to an occasional system lockup when run inside of VMware Workstation 6.
> It occurs in between calls to adapter bind or adapter unbind operations.
> I also tested using real hardware, but have yet to reproduce the issue.
> With debugging cranked up, all calls enter and exit our driver without
> any indication of an error. I’m also unable to produce this issue using
> the same driver binary and a Windows Vista VM.
>
> I’m afraid my kernel debugger knowledge is extremely limited. The only
> useful output obtained was using ‘KP’ or “stacktrace with source
> arguments” after performing a ‘break’. This consistently shows a call
> from NdisIMNotifyPnPEvent to the e1g60i32 Intel miniport driver …
>
> 8078adb8 826751ef nt!DbgBreakPointWithStatus+0x4
> 8078ae14 8267a577 nt!ObfReferenceObjectWithTag+0x65c
> ERROR: Module load completed but symbols could not be loaded for
> i8042prt.sys
> 8078ae38 8b2e7133 nt!KeUpdateSystemTime+0x13
> 8078ae9c 8264941d i8042prt+0x1133
> ERROR: Module load completed but symbols could not be loaded for
> E1G60I32.sys
> 8078aec0 8b37b837 nt!KeSynchronizeExecution+0x3d
> ERROR: Symbol file could not be found. Defaulted to export symbols
> for ndis.sys -
> 8078aee4 86c6f309 E1G60I32+0x837
> 8078af20 86c1a9f4 ndis!NdisIMNotifyPnPEvent+0x4c11
> 8078af48 826723b5 ndis!NdisDprReleaseReadWriteLock+0xca
> 8078afa4 82672218 nt!KiDispatchInterrupt+0xa05
> 8078aff4 826719dc nt!KiDispatchInterrupt+0x868
> ERROR: Symbol file could not be found. Defaulted to export symbols
> for halmacpi.dll -
> 807dfc94 82a1fb29 nt!KiDispatchInterrupt+0x2c
> 807dfcac 82a1fba9 hal!KeRaiseIrqlToSynchLevel+0x8f
> 807dfcbc 86c506c7 hal!KfLowerIrql+0x61
> 807dfd00 82677f2b ndis!NdisWritePciSlotInformation+0x386
> 807dfd50 8281866d nt!KeInsertQueueDpc+0x382
> 807dfd90 826ca0d9 nt!PsCreateSystemThread+0x19a
> 00000000 00000000 nt!wcsupr+0x13a
>
> The stack trace is pretty much identical for freezes that occur during
> either software installation or removal ( installs or uninstalls the LWF
> driver ). I’m just not familiar enough with network driver related call
> stacks to infer what could be causing this issue. I assume our driver is
> antagonizing the Intel driver in some way.
>
> I know the information I have to share is pretty lean, but does anyone
> have a suggestion? I’m totally stumped.
>
> Thanks in advance,
>
> -Matthew
>
> —
> NTDEV is sponsored by OSR
>
> 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
>
> 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

4

Sane, but lacking in information about your driver’s role in this. First, I guess that I would try ‘kb 20’ and post the results.

mm

5

Matthew,

The bind/unbind activity execute on system (NDIS) worker threads at
PASSIVE_LEVEL. This stack back-trace is simply the CPU/Thread combination
that happened to be servicing the DPC run-down when you pressed “Break-In”
on the debugger.

To locate the thread/stack(s) that are involved in NDIS activity you will
need to ask the debugger to enumerate all of the threads and kernel stacks
in the system and look at *that* data to find clues for why your operation
appears to be hanging.

The two commands I use to do this are:

!stacks 2 NDIS!

or

!process 0 7

The !process command can take quite a long time since it enumerates and
dumps the thread stacks for every thread in every process. For what you are
looking for, you can probably cut down the ‘haystack’ by first using the
!process command to just enumerate processes in the system. Find the
“System” process and then use the !process command with the “System” process
as the first argument. The NDIS worker threads are owned by the System
process.

Good Luck,
Dave Cattley

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Matthew Grooms
Sent: Tuesday, November 17, 2009 2:19 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] NDIS Related System Lock on VMware / Windows 7

Doron Holan wrote:

Fix your symbols first.

…symfix
…reload /f

And then

kb

To get a sane stack

Sent from my phone with no t9, all spilling mistakes are not intentional.

Thanks for the suggestion. Does this look more sane?

8078ad88 826a438f 00000001 826a4361 00000000
nt!RtlpBreakWithStatusInstruction
8078ad90 826a4361 00000000 00000000 0002625a nt!KdCheckForDebugBreak+0x22
8078adc0 826a41ef 8af7b72c 84efa008 00000000 nt!KeUpdateRunTime+0x164
8078ae1c 826a9577 8078ae02 8078ae02 000000d1 nt!KeUpdateSystemTime+0x613
8078ae1c 8af7b72c 8078ae02 8078ae02 000000d1
nt!KeUpdateSystemTimeAssist+0x13
8078aecc 8af7a77e 84efa008 853aaac0 00000000
E1G60I32!RxProcessReceiveInterrupts+0x40
8078aee4 86c73309 01efa008 00000000 8078af10
E1G60I32!E1000HandleInterrupt+0x80
8078af20 86c1e9f4 853aaad4 003aaac0 00000000 ndis!ndisMiniportDpc+0xe2
8078af48 826a13b5 853aaad4 853aaac0 00000000 ndis!ndisInterruptDpc+0xaf
8078afa4 826a1218 82762d20 85993548 00000000 nt!KiExecuteAllDpcs+0xf9
8078aff4 826a09dc 8a5bfc78 00000000 00000000 nt!KiRetireDpcList+0xd5
8078aff8 8a5bfc78 00000000 00000000 00000000 nt!KiDispatchInterrupt+0x2c

-Matthew

-----Original Message-----
From: Matthew Grooms
> Sent: Monday, November 16, 2009 10:32 PM
> To: Windows System Software Devs Interest List
> Subject: [ntdev] NDIS Related System Lock on VMware / Windows 7
>
>
> Hello All,
>
> I’m experiencing a really frustrating problem on Windows 7 that results
> in a system lockup. I hope someone with more network driver development
> knowledge can provide some insight into what the cause might be.
>
> We have an LWF driver that provides packet filtering and redirection. It
> functions without any issue after our software installation process has
> completed. However, some very difficult to understand circumstance leads
> to an occasional system lockup when run inside of VMware Workstation 6.
> It occurs in between calls to adapter bind or adapter unbind operations.
> I also tested using real hardware, but have yet to reproduce the issue.
> With debugging cranked up, all calls enter and exit our driver without
> any indication of an error. I’m also unable to produce this issue using
> the same driver binary and a Windows Vista VM.
>
> I’m afraid my kernel debugger knowledge is extremely limited. The only
> useful output obtained was using ‘KP’ or “stacktrace with source
> arguments” after performing a ‘break’. This consistently shows a call
> from NdisIMNotifyPnPEvent to the e1g60i32 Intel miniport driver …
>
> 8078adb8 826751ef nt!DbgBreakPointWithStatus+0x4
> 8078ae14 8267a577 nt!ObfReferenceObjectWithTag+0x65c
> ERROR: Module load completed but symbols could not be loaded for
> i8042prt.sys
> 8078ae38 8b2e7133 nt!KeUpdateSystemTime+0x13
> 8078ae9c 8264941d i8042prt+0x1133
> ERROR: Module load completed but symbols could not be loaded for
> E1G60I32.sys
> 8078aec0 8b37b837 nt!KeSynchronizeExecution+0x3d
> ERROR: Symbol file could not be found. Defaulted to export symbols
> for ndis.sys -
> 8078aee4 86c6f309 E1G60I32+0x837
> 8078af20 86c1a9f4 ndis!NdisIMNotifyPnPEvent+0x4c11
> 8078af48 826723b5 ndis!NdisDprReleaseReadWriteLock+0xca
> 8078afa4 82672218 nt!KiDispatchInterrupt+0xa05
> 8078aff4 826719dc nt!KiDispatchInterrupt+0x868
> ERROR: Symbol file could not be found. Defaulted to export symbols
> for halmacpi.dll -
> 807dfc94 82a1fb29 nt!KiDispatchInterrupt+0x2c
> 807dfcac 82a1fba9 hal!KeRaiseIrqlToSynchLevel+0x8f
> 807dfcbc 86c506c7 hal!KfLowerIrql+0x61
> 807dfd00 82677f2b ndis!NdisWritePciSlotInformation+0x386
> 807dfd50 8281866d nt!KeInsertQueueDpc+0x382
> 807dfd90 826ca0d9 nt!PsCreateSystemThread+0x19a
> 00000000 00000000 nt!wcsupr+0x13a
>
> The stack trace is pretty much identical for freezes that occur during
> either software installation or removal ( installs or uninstalls the LWF
> driver ). I’m just not familiar enough with network driver related call
> stacks to infer what could be causing this issue. I assume our driver is
> antagonizing the Intel driver in some way.
>
> I know the information I have to share is pretty lean, but does anyone
> have a suggestion? I’m totally stumped.
>
> Thanks in advance,
>
> -Matthew
>
> —
> NTDEV is sponsored by OSR
>
> 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
>
> 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

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

6

David R. Cattley wrote:

Matthew,

The bind/unbind activity execute on system (NDIS) worker threads at
PASSIVE_LEVEL. This stack back-trace is simply the CPU/Thread combination
that happened to be servicing the DPC run-down when you pressed “Break-In”
on the debugger.

To locate the thread/stack(s) that are involved in NDIS activity you will
need to ask the debugger to enumerate all of the threads and kernel stacks
in the system and look at *that* data to find clues for why your operation
appears to be hanging.

The two commands I use to do this are:

!stacks 2 NDIS!

or

!process 0 7

The !process command can take quite a long time since it enumerates and
dumps the thread stacks for every thread in every process. For what you are
looking for, you can probably cut down the ‘haystack’ by first using the
!process command to just enumerate processes in the system. Find the
“System” process and then use the !process command with the “System” process
as the first argument. The NDIS worker threads are owned by the System
process.

Hi David,

Thanks for you help. I see five threads related to NDIS activity in the
system process. Unfortunately, none of them appear to reference any of
our kernel drivers. It does appear that one of them is hung in a pause
state. Something is obviously spinning in a tight loop as the core used
by VMware for this VM is pegged at 100%. In any case, here is the output
from the debugger …

THREAD 84c3c020 Cid 0004.00b0 Teb: 00000000 Win32Thread:
00000000 WAIT: (Executive) KernelMode Non-Alertable
86c604e0 SynchronizationTimer
Not impersonating
DeviceMap 87808a00
Owning Process 83dbc020 Image: System
Attached Process N/A Image: N/A
Wait Start TickCount 1827 Ticks: 36144
(0:00:09:24.750)
Context Switch Count 5
UserTime 00:00:00.000
KernelTime 00:00:00.000
Win32 Start Address ndis!ndisThreadPoolTimerHandler (0x86c38653)
Stack Init 8a741fd0 Current 8a741c30 Base 8a742000 Limit
8a73f000 Call 0
Priority 7 BasePriority 7 UnusualBoost 0 ForegroundBoost 0
IoPriority 2 PagePriority 5
ChildEBP RetAddr Args to Child
8a741c48 826a7b15 84c3c020 00000000 82762d20
nt!KiSwapContext+0x26 (FPO: [Uses EBP] [0,0,4])
8a741c80 826a6403 84c3c0e0 84c3c020 86c604e0 nt!KiSwapThread+0x266
8a741ca8 826a02cf 84c3c020 84c3c0e0 00000000
nt!KiCommitThreadWait+0x1df
8a741d24 86c3872c 86c604e0 00000000 00000000
nt!KeWaitForSingleObject+0x393
8a741d50 8284766d 00000000 247c511d 00000000
ndis!ndisThreadPoolTimerHandler+0xd9 (FPO: [1,1,4])
8a741d90 826f90d9 86c38653 00000000 00000000
nt!PspSystemThreadStartup+0x9e
00000000 00000000 00000000 00000000 00000000
nt!KiThreadStartup+0x19

THREAD 84c3cd48 Cid 0004.00b4 Teb: 00000000 Win32Thread:
00000000 WAIT: (WrQueue) KernelMode Non-Alertable
86c60520 QueueObject
Not impersonating
DeviceMap 87808a00
Owning Process 83dbc020 Image: System
Attached Process N/A Image: N/A
Wait Start TickCount 1788 Ticks: 36183
(0:00:09:25.359)
Context Switch Count 63
UserTime 00:00:00.000
KernelTime 00:00:00.031
Win32 Start Address ndis!ndisWorkerThread (0x86c28636)
Stack Init 8a745fd0 Current 8a745c30 Base 8a746000 Limit
8a743000 Call 0
Priority 8 BasePriority 8 UnusualBoost 0 ForegroundBoost 0
IoPriority 2 PagePriority 5
ChildEBP RetAddr Args to Child
8a745c48 826a7b15 84c3cd48 00000000 82762d20
nt!KiSwapContext+0x26 (FPO: [Uses EBP] [0,0,4])
8a745c80 826a6403 84c3ce08 84c3cd48 86c60520 nt!KiSwapThread+0x266
8a745ca8 826a766d 84c3cd48 84c3ce08 00000000
nt!KiCommitThreadWait+0x1df
8a745d0c 826fb156 86c60520 00000000 00000000
nt!KeRemoveQueueEx+0x4f8
8a745d2c 86c28658 86c60520 00000000 00000000 nt!KeRemoveQueue+0x1b
8a745d50 8284766d 00000000 247c111d 00000000
ndis!ndisWorkerThread+0x22 (FPO: [1,1,4])
8a745d90 826f90d9 86c28636 00000000 00000000
nt!PspSystemThreadStartup+0x9e
00000000 00000000 00000000 00000000 00000000
nt!KiThreadStartup+0x19

THREAD 84c3fc28 Cid 0004.00b8 Teb: 00000000 Win32Thread:
00000000 ???
Not impersonating
DeviceMap 87808a00
Owning Process 83dbc020 Image: System
Attached Process N/A Image: N/A
Wait Start TickCount 33393 Ticks: 4578
(0:00:01:11.531)
Context Switch Count 17
UserTime 00:00:00.000
KernelTime 00:00:00.000
Win32 Start Address ndis!ndisCmWaitThread (0x86c1f225)
Stack Init 8a749fd0 Current 8a749c30 Base 8a74a000 Limit
8a747000 Call 0
Priority 8 BasePriority 8 UnusualBoost 0 ForegroundBoost 0
IoPriority 2 PagePriority 5
ChildEBP RetAddr Args to Child
8a749c48 826a7b15 84c3fc28 00000000 82762d20
nt!KiSwapContext+0x26 (FPO: [Uses EBP] [0,0,4])
8a749c80 826a6403 84c3fce8 84c3fc28 86c5f810 nt!KiSwapThread+0x266
8a749ca8 826a02cf 84c3fc28 84c3fce8 000000ee
nt!KiCommitThreadWait+0x1df
8a749d20 86c1f280 86c5f810 00000000 00000000
nt!KeWaitForSingleObject+0x393
8a749d50 8284766d 00000000 247cd11d 00000000
ndis!ndisCmWaitThread+0x5b (FPO: [1,2,4])
8a749d90 826f90d9 86c1f225 00000000 00000000
nt!PspSystemThreadStartup+0x9e
00000000 00000000 00000000 00000000 00000000
nt!KiThreadStartup+0x19

THREAD 84e6c448 Cid 0004.014c Teb: 00000000 Win32Thread:
00000000 WAIT: (WrQueue) KernelMode Non-Alertable
86c60520 QueueObject
Not impersonating
DeviceMap 87808a00
Owning Process 83dbc020 Image: System
Attached Process N/A Image: N/A
Wait Start TickCount 32025 Ticks: 5946
(0:00:01:32.906)
Context Switch Count 478
UserTime 00:00:00.000
KernelTime 00:00:01.078
Win32 Start Address ndis!ndisWorkerThread (0x86c28636)
Stack Init 807cefd0 Current 807cec30 Base 807cf000 Limit
807cc000 Call 0
Priority 8 BasePriority 8 UnusualBoost 0 ForegroundBoost 0
IoPriority 2 PagePriority 5
ChildEBP RetAddr Args to Child
807cec48 826a7b15 84e6c448 00000000 82762d20
nt!KiSwapContext+0x26 (FPO: [Uses EBP] [0,0,4])
807cec80 826a6403 84e6c508 84e6c448 86c60520 nt!KiSwapThread+0x266
807ceca8 826a766d 84e6c448 84e6c508 00000000
nt!KiCommitThreadWait+0x1df
807ced0c 826fb156 86c60520 00000000 00000000
nt!KeRemoveQueueEx+0x4f8
807ced2c 86c28658 86c60520 00000000 00000000 nt!KeRemoveQueue+0x1b
807ced50 8284766d 00000000 2e74a11d 00000000
ndis!ndisWorkerThread+0x22 (FPO: [1,1,4])
807ced90 826f90d9 86c28636 00000000 00000000
nt!PspSystemThreadStartup+0x9e
00000000 00000000 00000000 00000000 00000000
nt!KiThreadStartup+0x19

THREAD 85993548 Cid 0004.0d28 Teb: 00000000 Win32Thread:
00000000 RUNNING on processor 0
Not impersonating
DeviceMap 87808a00
Owning Process 83dbc020 Image: System
Attached Process N/A Image: N/A
Wait Start TickCount 37449 Ticks: 522
(0:00:00:08.156)
Context Switch Count 3160
UserTime 00:00:00.000
KernelTime 00:00:00.437
Win32 Start Address nt!ExpWorkerThread (0x826a6e1e)
Stack Init 8a5bffd0 Current 8a5bfc68 Base 8a5c0000 Limit
8a5bd000 Call 0
Priority 13 BasePriority 13 UnusualBoost 0 ForegroundBoost 0
IoPriority 2 PagePriority 5
ChildEBP RetAddr Args to Child
8078ac88 826a438f 00000001 826a4361 00000000
nt!RtlpBreakWithStatusInstruction (FPO: [1,0,0])
8078ac90 826a4361 00000000 00000000 0002625a
nt!KdCheckForDebugBreak+0x22 (FPO: [0,0,0])
8078acc0 826a41ef 8af7a899 84e420e0 00000000
nt!KeUpdateRunTime+0x164
8078ad18 826a9577 00000008 00000008 000000d1
nt!KeUpdateSystemTime+0x613
8078ad18 8af7a899 00000008 00000008 000000d1
nt!KeUpdateSystemTimeAssist+0x13 (FPO: [0,2] TrapFrame @ 8078ad2c)
8078ada4 86c84317 84efa008 8078add7 8078adcc
E1G60I32!E1000ISR+0x43 (FPO: [3,0,4])
8078add8 826787ad 84eb3280 853aaac0 8078ae04
ndis!ndisMiniportIsr+0x67 (FPO: [2,5,4])
8078add8 82604d3a 84eb3280 853aaac0 8078ae04
nt!KiInterruptDispatch+0x6d (FPO: [0,2] TrapFrame @ 8078ae04)
8078ae74 82607a4d 00000001 84efa008 84efa002
hal!HalpGenerateInterrupt+0x266 (FPO: [0,0,0])
8078ae94 82607ba0 84efa008 853aa802 8078aec0
hal!HalpLowerIrqlHardwareInterrupts+0xf5 (FPO: [0,3,4])
8078aea4 8267842a 853aaa00 86c7b2ef 853aa838
hal!KfLowerIrql+0x58 (FPO: [0,1,4])
8078aec0 8af7a837 853aaac0 00000000 8af7a634
nt!KeSynchronizeExecution+0x4a
8078aee4 86c73309 01efa008 00000000 8078af10
E1G60I32!E1000HandleInterrupt+0x139 (FPO: [4,0,4])
8078af20 86c1e9f4 853aaad4 003aaac0 00000000
ndis!ndisMiniportDpc+0xe2 (FPO: [4,6,4])
8078af48 826a13b5 853aaad4 853aaac0 00000000
ndis!ndisInterruptDpc+0xaf (FPO: [4,1,4])
8078afa4 826a1218 82762d20 85993548 00000000
nt!KiExecuteAllDpcs+0xf9
8078aff4 826a09dc 8a5bfc78 00000000 00000000
nt!KiRetireDpcList+0xd5
8078aff8 8a5bfc78 00000000 00000000 00000000
nt!KiDispatchInterrupt+0x2c (FPO: [Uses EBP] [0,0,1])
WARNING: Frame IP not in any known module. Following frames may be wrong.
826a09dc 00000000 0000001a 00d6850f bb830000 0x8a5bfc78

The only other process that showed anything NDIS related was our install
helper application. It adds the LWF network component using code lifted
from the DDK. Here are the threads for that process …

PROCESS 83fd7468 SessionId: 1 Cid: 02a4 Peb: 7ffd5000 ParentCid: 0b1c
DirBase: 3ec34620 ObjectTable: 93cfb498 HandleCount: 235.
Image: netcfg.exe
VadRoot 857c8400 Vads 123 Clone 0 Private 712. Modified 174. Locked 0.
DeviceMap 90334710
Token a0147030
ElapsedTime 00:01:36.640
UserTime 00:00:00.000
KernelTime 00:00:00.031
QuotaPoolUsage[PagedPool] 0
QuotaPoolUsage[NonPagedPool] 0
Working Set Sizes (now,min,max) (2602, 50, 345) (10408KB, 200KB,
1380KB)
PeakWorkingSetSize 2603
VirtualSize 73 Mb
PeakVirtualSize 73 Mb
PageFaultCount 4897
MemoryPriority BACKGROUND
BasePriority 8
CommitCharge 1087
Job 83e5ba90

THREAD 8564c4b8 Cid 02a4.0aac Teb: 7ffdf000 Win32Thread:
fe996dd8 ???
IRP List:
83ddc4d8: (0006,0094) Flags: 00060030 Mdl: 00000000
840a1cc0: (0006,01d8) Flags: 00060000 Mdl: 00000000
Not impersonating
DeviceMap 90334710
Owning Process 83fd7468 Image: netcfg.exe
Attached Process N/A Image: N/A
Wait Start TickCount 33393 Ticks: 4578
(0:00:01:11.531)
Context Switch Count 698
UserTime 00:00:00.093
KernelTime 00:00:00.671
Win32 Start Address 0x0100342b
Stack Init 914b3fd0 Current 914b3810 Base 914b4000 Limit
914b1000 Call 0
Priority 11 BasePriority 8 UnusualBoost 0 ForegroundBoost 2
IoPriority 2 PagePriority 5
ChildEBP RetAddr Args to Child
914b3828 826a7b15 8564c4b8 00000000 82762d20
nt!KiSwapContext+0x26 (FPO: [Uses EBP] [0,0,4])
914b3860 826a6403 8564c578 8564c4b8 914b3920 nt!KiSwapThread+0x266
914b3888 826a02cf 8564c4b8 8564c578 00000000
nt!KiCommitThreadWait+0x1df
914b3900 86c916bb 914b3920 00000000 00000000
nt!KeWaitForSingleObject+0x393
914b3948 8af7da31 00030d40 84e42110 84e420e0
ndis!NdisMSleep+0x55 (FPO: [1,10,4])
914b3964 86c9132a 84efa008 914b3990 00000008
E1G60I32!E1000Pause+0x33 (FPO: [2,1,4])
914b39a0 86c92573 00e420e0 00000008 84e420e0
ndis!ndisPauseMiniport+0x190 (FPO: [2,8,4])
914b3a10 86c2a0fc 00e420e0 00000000 00000000
ndis!ndisCloseMiniportBindingsForPause+0x1be (FPO: [2,21,4])
914b3b44 86ca2827 841aa5d0 00000000 84e420e0
ndis!ndisAttachFilterToMiniport+0x298 (FPO: [3,70,4])
914b3b84 86c93950 858fac90 858fac98 00000000
ndis!ndisHandleFilterAttachNotification+0x1a5 (FPO: [2,8,4])
914b3ba8 86c8e3b8 858fac98 00000000 83ddc4d8
ndis!ndisHandleUModePnPOp+0x283 (FPO: [1,2,4])
914b3bdc 86c8e57e 83ddc4d8 8404c120 84c3b720
ndis!ndisHandlePnPRequest+0x378 (FPO: [1,7,4])
914b3bfc 826754bc 84c3b720 83ddc4d8 83ddc4d8
ndis!ndisDispatchRequest+0x8a (FPO: [2,2,4])
914b3c14 82876eee 8404c120 83ddc4d8 83ddc548 nt!IofCallDriver+0x63
914b3c34 82893cd1 84c3b720 8404c120 00000000
nt!IopSynchronousServiceTail+0x1f8
914b3cd0 828964ac 84c3b720 83ddc4d8 00000000
nt!IopXxxControlFile+0x6aa
914b3d04 8267c42a 000003dc 00000000 00000000
nt!NtDeviceIoControlFile+0x2a
914b3d04 771664f4 000003dc 00000000 00000000
nt!KiFastCallEntry+0x12a (FPO: [0,3] TrapFrame @ 914b3d34)
WARNING: Frame IP not in any known module. Following frames may be wrong.
0006f484 00000000 00000000 00000000 00000000 0x771664f4

THREAD 8597e8a8 Cid 02a4.0974 Teb: 7ffde000 Win32Thread:
ffabc250 WAIT: (WrUserRequest) UserMode Non-Alertable
85881af8 SynchronizationEvent
Not impersonating
DeviceMap 90334710
Owning Process 83fd7468 Image: netcfg.exe
Attached Process N/A Image: N/A
Wait Start TickCount 31928 Ticks: 6043
(0:00:01:34.421)
Context Switch Count 27
UserTime 00:00:00.000
KernelTime 00:00:00.062
Win32 Start Address 0x010026a0
Stack Init 93983fd0 Current 93983af8 Base 93984000 Limit
93981000 Call 0
Priority 12 BasePriority 8 UnusualBoost 0 ForegroundBoost 2
IoPriority 2 PagePriority 5
ChildEBP RetAddr Args to Child
93983b10 826a7b15 8597e8a8 82765f08 82762d20
nt!KiSwapContext+0x26 (FPO: [Uses EBP] [0,0,4])
93983b48 826a6403 8597e968 8597e8a8 85881af8 nt!KiSwapThread+0x266
93983b70 826a02cf 8597e8a8 8597e968 00000000
nt!KiCommitThreadWait+0x1df
93983be8 8f990d75 85881af8 0000000d 00000001
nt!KeWaitForSingleObject+0x393
93983c44 8f990e10 000025ff 00000000 00000001
win32k!xxxRealSleepThread+0x1d7 (FPO: [SEH])
93983c60 8f989a86 000025ff 00000000 00000001
win32k!xxxSleepThread+0x2d (FPO: [3,0,0])
93983cb8 8f990e6b 93983ce8 000025ff 00000000
win32k!xxxRealInternalGetMessage+0x4b2 (FPO: [SEH])
93983d1c 8267c42a 0034feb8 00000000 00000000
win32k!NtUserGetMessage+0x3f (FPO: [SEH])
93983d1c 771664f4 0034feb8 00000000 00000000
nt!KiFastCallEntry+0x12a (FPO: [0,3] TrapFrame @ 93983d34)
WARNING: Frame IP not in any known module. Following frames may be wrong.
0034fe94 00000000 00000000 00000000 00000000 0x771664f4

THREAD 83fb8198 Cid 02a4.0b50 Teb: 7ffdd000 Win32Thread:
00000000 ???
Not impersonating
DeviceMap 90334710
Owning Process 83fd7468 Image: netcfg.exe
Attached Process N/A Image: N/A
Wait Start TickCount 34745 Ticks: 3226
(0:00:00:50.406)
Context Switch Count 89
UserTime 00:00:00.000
KernelTime 00:00:00.000
Win32 Start Address 0x7714edfb
Stack Init 938dffd0 Current 938df748 Base 938e0000 Limit
938dd000 Call 0
Priority 12 BasePriority 8 UnusualBoost 0 ForegroundBoost 2
IoPriority 2 PagePriority 5
ChildEBP RetAddr Args to Child
938df760 826a7b15 83fb8198 82765f08 82762d20
nt!KiSwapContext+0x26 (FPO: [Uses EBP] [0,0,4])
938df798 826a6403 83e8ab58 83fb8198 841422b4 nt!KiSwapThread+0x266
938df7c0 826a26ef 83fb8198 84142008 00000000
nt!KiCommitThreadWait+0x1df
938df93c 8286b625 0000001c 938dfa74 00000001
nt!KeWaitForMultipleObjects+0x535
938dfbc8 8286b392 0000001c 938dfc64 00000001
nt!ObpWaitForMultipleObjects+0x262
938dfd18 8267c42a 0000001c 0018afd0 00000001
nt!NtWaitForMultipleObjects+0xcd
938dfd18 771664f4 0000001c 0018afd0 00000001
nt!KiFastCallEntry+0x12a (FPO: [0,3] TrapFrame @ 938dfd34)
WARNING: Frame IP not in any known module. Following frames may be wrong.
0067ff88 00000000 00000000 00000000 00000000 0x771664f4

THREAD 8422fd48 Cid 02a4.0dd4 Teb: 7ffdc000 Win32Thread:
00000000 ???
Not impersonating
DeviceMap 90334710
Owning Process 83fd7468 Image: netcfg.exe
Attached Process N/A Image: N/A
Wait Start TickCount 33393 Ticks: 4578
(0:00:01:11.531)
Context Switch Count 1
UserTime 00:00:00.000
KernelTime 00:00:00.000
Win32 Start Address 0x753a7bbd
Stack Init 938c3fd0 Current 938c3748 Base 938c4000 Limit
938c1000 Call 0
Priority 10 BasePriority 8 UnusualBoost 0 ForegroundBoost 2
IoPriority 2 PagePriority 5
ChildEBP RetAddr Args to Child
938c3760 826a7b15 8422fd48 82765f08 82762d20
nt!KiSwapContext+0x26 (FPO: [Uses EBP] [0,0,4])
938c3798 826a6403 00000000 8422fd48 8422fe2c nt!KiSwapThread+0x266
938c37c0 826a26ef 8422fd48 8422fe08 00000045
nt!KiCommitThreadWait+0x1df
938c393c 8286b625 00000001 938c3a74 00000001
nt!KeWaitForMultipleObjects+0x535
938c3bc8 8286b392 00000001 938c3bf8 00000001
nt!ObpWaitForMultipleObjects+0x262
938c3d18 8267c42a 00000001 008dfecc 00000001
nt!NtWaitForMultipleObjects+0xcd
938c3d18 771664f4 00000001 008dfecc 00000001
nt!KiFastCallEntry+0x12a (FPO: [0,3] TrapFrame @ 938c3d34)
WARNING: Frame IP not in any known module. Following frames may be wrong.
008dff18 00000000 00000000 00000000 00000000 0x771664f4

THREAD 841e0d48 Cid 02a4.0f20 Teb: 7ffdb000 Win32Thread:
00000000 WAIT: (WrQueue) UserMode Alertable
840258d8 QueueObject
Not impersonating
DeviceMap 90334710
Owning Process 83fd7468 Image: netcfg.exe
Attached Process N/A Image: N/A
Wait Start TickCount 31877 Ticks: 6094
(0:00:01:35.218)
Context Switch Count 2
UserTime 00:00:00.000
KernelTime 00:00:00.000
Win32 Start Address 0x7714d63e
Stack Init 88bc0fd0 Current 88bc0b60 Base 88bc1000 Limit
88bbe000 Call 0
Priority 8 BasePriority 8 UnusualBoost 0 ForegroundBoost 0
IoPriority 2 PagePriority 5
ChildEBP RetAddr Args to Child
88bc0b78 826a7b15 841e0d48 82765f08 82762d20
nt!KiSwapContext+0x26 (FPO: [Uses EBP] [0,0,4])
88bc0bb0 826a6403 841e0e08 841e0d48 840258d8 nt!KiSwapThread+0x266
88bc0bd8 826a766d 841e0d48 841e0e08 00000000
nt!KiCommitThreadWait+0x1df
88bc0c38 8286a71d 840258d8 826eaf01 00000001
nt!KeRemoveQueueEx+0x4f8
88bc0c90 826aace6 840258d8 88bc0cc8 88bc0cf0
nt!IoRemoveIoCompletion+0x23
88bc0d24 8267c42a 00000260 0091fedc 0091ff88
nt!NtWaitForWorkViaWorkerFactory+0x1a1
88bc0d24 771664f4 00000260 0091fedc 0091ff88
nt!KiFastCallEntry+0x12a (FPO: [0,3] TrapFrame @ 88bc0d34)
WARNING: Frame IP not in any known module. Following frames may be wrong.
0091ff88 00000000 00000000 00000000 00000000 0x771664f4

THREAD 85875c90 Cid 02a4.07e4 Teb: 7ffda000 Win32Thread:
00000000 ???
Not impersonating
DeviceMap 90334710
Owning Process 83fd7468 Image: netcfg.exe
Attached Process N/A Image: N/A
Wait Start TickCount 37449 Ticks: 522
(0:00:00:08.156)
Context Switch Count 2
UserTime 00:00:00.000
KernelTime 00:00:00.000
Win32 Start Address 0x7714d63e
Stack Init 88bf0fd0 Current 88bf0b60 Base 88bf1000 Limit
88bee000 Call 0
Priority 10 BasePriority 8 UnusualBoost 0 ForegroundBoost 2
IoPriority 2 PagePriority 5
ChildEBP RetAddr Args to Child
88bf0b78 826a7b15 85875c90 82765f08 82762d20
nt!KiSwapContext+0x26 (FPO: [Uses EBP] [0,0,4])
88bf0bb0 826a6403 85875d50 85875c90 841bc1e8 nt!KiSwapThread+0x266
88bf0bd8 826a766d 85875c90 85875d50 00000047
nt!KiCommitThreadWait+0x1df
88bf0c38 8286a71d 841bc1e8 826eaf01 00000001
nt!KeRemoveQueueEx+0x4f8
88bf0c90 826aace6 841bc1e8 88bf0cc8 88bf0cf0
nt!IoRemoveIoCompletion+0x23
88bf0d24 8267c42a 00000160 00f2fedc 00f2ff88
nt!NtWaitForWorkViaWorkerFactory+0x1a1
88bf0d24 771664f4 00000160 00f2fedc 00f2ff88
nt!KiFastCallEntry+0x12a (FPO: [0,3] TrapFrame @ 88bf0d34)
WARNING: Frame IP not in any known module. Following frames may be wrong.
00f2ff88 00000000 00000000 00000000 00000000 0x771664f4

Could our installer application be doing something that actually locks
up the system? I wouldn’t think that would be possible. It essentially
just calls the HrInstallNetComponent function from component.cpp, an
example I found in one of the DDKs. It appears to call SetupCopyOEMInf,
then INetCfg::QueryNetCfgClass() using IID_INetCfgClassSetup and finally
pncClassSetup->Install(). The only parameters I pass to the DDK source
code is a class GUID_DEVCLASS_NETSERVICE, the inf file path and the inf
component ID name.

Is there another, better way to install a network filter service?

-Matthew

7

Are you running on VMWare 6.5 or 7?

VMWare 7 (released very recently…) is the first version to “formally”
support Windows 7. I haven’t looked at the release notes in sufficient
detail to know if there were any fixes related to this behavior.

Thomas F. Divine

From: “Matthew Grooms”
Sent: Tuesday, November 17, 2009 1:50 PM
To: “Windows System Software Devs Interest List”
Subject: Re: [ntdev] NDIS Related System Lock on VMware / Windows 7

> David R. Cattley wrote:
>> Matthew,
>>
>> The bind/unbind activity execute on system (NDIS) worker threads at
>> PASSIVE_LEVEL. This stack back-trace is simply the CPU/Thread
>> combination
>> that happened to be servicing the DPC run-down when you pressed
>> “Break-In”
>> on the debugger.
>>
>> To locate the thread/stack(s) that are involved in NDIS activity you will
>> need to ask the debugger to enumerate all of the threads and kernel
>> stacks
>> in the system and look at that data to find clues for why your
>> operation
>> appears to be hanging.
>>
>> The two commands I use to do this are:
>>
>> !stacks 2 NDIS!
>>
>> or
>>
>> !process 0 7
>>
>> The !process command can take quite a long time since it enumerates and
>> dumps the thread stacks for every thread in every process. For what you
>> are
>> looking for, you can probably cut down the ‘haystack’ by first using the
>> !process command to just enumerate processes in the system. Find the
>> “System” process and then use the !process command with the “System”
>> process
>> as the first argument. The NDIS worker threads are owned by the System
>> process.
>>
>
> Hi David,
>
> Thanks for you help. I see five threads related to NDIS activity in the
> system process. Unfortunately, none of them appear to reference any of our
> kernel drivers. It does appear that one of them is hung in a pause state.
> Something is obviously spinning in a tight loop as the core used by VMware
> for this VM is pegged at 100%. In any case, here is the output from the
> debugger …
>
> -----------------------------------------------------------------------
>
> THREAD 84c3c020 Cid 0004.00b0 Teb: 00000000 Win32Thread:
> 00000000 WAIT: (Executive) KernelMode Non-Alertable
> 86c604e0 SynchronizationTimer
> Not impersonating
> DeviceMap 87808a00
> Owning Process 83dbc020 Image: System
> Attached Process N/A Image: N/A
> Wait Start TickCount 1827 Ticks: 36144
> (0:00:09:24.750)
> Context Switch Count 5
> UserTime 00:00:00.000
> KernelTime 00:00:00.000
> Win32 Start Address ndis!ndisThreadPoolTimerHandler (0x86c38653)
> Stack Init 8a741fd0 Current 8a741c30 Base 8a742000 Limit 8a73f000
> Call 0
> Priority 7 BasePriority 7 UnusualBoost 0 ForegroundBoost 0
> IoPriority 2 PagePriority 5
> ChildEBP RetAddr Args to Child
> 8a741c48 826a7b15 84c3c020 00000000 82762d20 nt!KiSwapContext+0x26
> (FPO: [Uses EBP] [0,0,4])
> 8a741c80 826a6403 84c3c0e0 84c3c020 86c604e0 nt!KiSwapThread+0x266
> 8a741ca8 826a02cf 84c3c020 84c3c0e0 00000000
> nt!KiCommitThreadWait+0x1df
> 8a741d24 86c3872c 86c604e0 00000000 00000000
> nt!KeWaitForSingleObject+0x393
> 8a741d50 8284766d 00000000 247c511d 00000000
> ndis!ndisThreadPoolTimerHandler+0xd9 (FPO: [1,1,4])
> 8a741d90 826f90d9 86c38653 00000000 00000000
> nt!PspSystemThreadStartup+0x9e
> 00000000 00000000 00000000 00000000 00000000
> nt!KiThreadStartup+0x19
>
> THREAD 84c3cd48 Cid 0004.00b4 Teb: 00000000 Win32Thread:
> 00000000 WAIT: (WrQueue) KernelMode Non-Alertable
> 86c60520 QueueObject
> Not impersonating
> DeviceMap 87808a00
> Owning Process 83dbc020 Image: System
> Attached Process N/A Image: N/A
> Wait Start TickCount 1788 Ticks: 36183
> (0:00:09:25.359)
> Context Switch Count 63
> UserTime 00:00:00.000
> KernelTime 00:00:00.031
> Win32 Start Address ndis!ndisWorkerThread (0x86c28636)
> Stack Init 8a745fd0 Current 8a745c30 Base 8a746000 Limit 8a743000
> Call 0
> Priority 8 BasePriority 8 UnusualBoost 0 ForegroundBoost 0
> IoPriority 2 PagePriority 5
> ChildEBP RetAddr Args to Child
> 8a745c48 826a7b15 84c3cd48 00000000 82762d20 nt!KiSwapContext+0x26
> (FPO: [Uses EBP] [0,0,4])
> 8a745c80 826a6403 84c3ce08 84c3cd48 86c60520 nt!KiSwapThread+0x266
> 8a745ca8 826a766d 84c3cd48 84c3ce08 00000000
> nt!KiCommitThreadWait+0x1df
> 8a745d0c 826fb156 86c60520 00000000 00000000
> nt!KeRemoveQueueEx+0x4f8
> 8a745d2c 86c28658 86c60520 00000000 00000000 nt!KeRemoveQueue+0x1b
> 8a745d50 8284766d 00000000 247c111d 00000000
> ndis!ndisWorkerThread+0x22 (FPO: [1,1,4])
> 8a745d90 826f90d9 86c28636 00000000 00000000
> nt!PspSystemThreadStartup+0x9e
> 00000000 00000000 00000000 00000000 00000000
> nt!KiThreadStartup+0x19
>
> THREAD 84c3fc28 Cid 0004.00b8 Teb: 00000000 Win32Thread:
> 00000000 ???
> Not impersonating
> DeviceMap 87808a00
> Owning Process 83dbc020 Image: System
> Attached Process N/A Image: N/A
> Wait Start TickCount 33393 Ticks: 4578
> (0:00:01:11.531)
> Context Switch Count 17
> UserTime 00:00:00.000
> KernelTime 00:00:00.000
> Win32 Start Address ndis!ndisCmWaitThread (0x86c1f225)
> Stack Init 8a749fd0 Current 8a749c30 Base 8a74a000 Limit 8a747000
> Call 0
> Priority 8 BasePriority 8 UnusualBoost 0 ForegroundBoost 0
> IoPriority 2 PagePriority 5
> ChildEBP RetAddr Args to Child
> 8a749c48 826a7b15 84c3fc28 00000000 82762d20 nt!KiSwapContext+0x26
> (FPO: [Uses EBP] [0,0,4])
> 8a749c80 826a6403 84c3fce8 84c3fc28 86c5f810 nt!KiSwapThread+0x266
> 8a749ca8 826a02cf 84c3fc28 84c3fce8 000000ee
> nt!KiCommitThreadWait+0x1df
> 8a749d20 86c1f280 86c5f810 00000000 00000000
> nt!KeWaitForSingleObject+0x393
> 8a749d50 8284766d 00000000 247cd11d 00000000
> ndis!ndisCmWaitThread+0x5b (FPO: [1,2,4])
> 8a749d90 826f90d9 86c1f225 00000000 00000000
> nt!PspSystemThreadStartup+0x9e
> 00000000 00000000 00000000 00000000 00000000
> nt!KiThreadStartup+0x19
>
> THREAD 84e6c448 Cid 0004.014c Teb: 00000000 Win32Thread:
> 00000000 WAIT: (WrQueue) KernelMode Non-Alertable
> 86c60520 QueueObject
> Not impersonating
> DeviceMap 87808a00
> Owning Process 83dbc020 Image: System
> Attached Process N/A Image: N/A
> Wait Start TickCount 32025 Ticks: 5946
> (0:00:01:32.906)
> Context Switch Count 478
> UserTime 00:00:00.000
> KernelTime 00:00:01.078
> Win32 Start Address ndis!ndisWorkerThread (0x86c28636)
> Stack Init 807cefd0 Current 807cec30 Base 807cf000 Limit 807cc000
> Call 0
> Priority 8 BasePriority 8 UnusualBoost 0 ForegroundBoost 0
> IoPriority 2 PagePriority 5
> ChildEBP RetAddr Args to Child
> 807cec48 826a7b15 84e6c448 00000000 82762d20 nt!KiSwapContext+0x26
> (FPO: [Uses EBP] [0,0,4])
> 807cec80 826a6403 84e6c508 84e6c448 86c60520 nt!KiSwapThread+0x266
> 807ceca8 826a766d 84e6c448 84e6c508 00000000
> nt!KiCommitThreadWait+0x1df
> 807ced0c 826fb156 86c60520 00000000 00000000
> nt!KeRemoveQueueEx+0x4f8
> 807ced2c 86c28658 86c60520 00000000 00000000 nt!KeRemoveQueue+0x1b
> 807ced50 8284766d 00000000 2e74a11d 00000000
> ndis!ndisWorkerThread+0x22 (FPO: [1,1,4])
> 807ced90 826f90d9 86c28636 00000000 00000000
> nt!PspSystemThreadStartup+0x9e
> 00000000 00000000 00000000 00000000 00000000
> nt!KiThreadStartup+0x19
>
> THREAD 85993548 Cid 0004.0d28 Teb: 00000000 Win32Thread:
> 00000000 RUNNING on processor 0
> Not impersonating
> DeviceMap 87808a00
> Owning Process 83dbc020 Image: System
> Attached Process N/A Image: N/A
> Wait Start TickCount 37449 Ticks: 522
> (0:00:00:08.156)
> Context Switch Count 3160
> UserTime 00:00:00.000
> KernelTime 00:00:00.437
> Win32 Start Address nt!ExpWorkerThread (0x826a6e1e)
> Stack Init 8a5bffd0 Current 8a5bfc68 Base 8a5c0000 Limit 8a5bd000
> Call 0
> Priority 13 BasePriority 13 UnusualBoost 0 ForegroundBoost 0
> IoPriority 2 PagePriority 5
> ChildEBP RetAddr Args to Child
> 8078ac88 826a438f 00000001 826a4361 00000000
> nt!RtlpBreakWithStatusInstruction (FPO: [1,0,0])
> 8078ac90 826a4361 00000000 00000000 0002625a
> nt!KdCheckForDebugBreak+0x22 (FPO: [0,0,0])
> 8078acc0 826a41ef 8af7a899 84e420e0 00000000
> nt!KeUpdateRunTime+0x164
> 8078ad18 826a9577 00000008 00000008 000000d1
> nt!KeUpdateSystemTime+0x613
> 8078ad18 8af7a899 00000008 00000008 000000d1
> nt!KeUpdateSystemTimeAssist+0x13 (FPO: [0,2] TrapFrame @ 8078ad2c)
> 8078ada4 86c84317 84efa008 8078add7 8078adcc
> E1G60I32!E1000ISR+0x43 (FPO: [3,0,4])
> 8078add8 826787ad 84eb3280 853aaac0 8078ae04
> ndis!ndisMiniportIsr+0x67 (FPO: [2,5,4])
> 8078add8 82604d3a 84eb3280 853aaac0 8078ae04
> nt!KiInterruptDispatch+0x6d (FPO: [0,2] TrapFrame @ 8078ae04)
> 8078ae74 82607a4d 00000001 84efa008 84efa002
> hal!HalpGenerateInterrupt+0x266 (FPO: [0,0,0])
> 8078ae94 82607ba0 84efa008 853aa802 8078aec0
> hal!HalpLowerIrqlHardwareInterrupts+0xf5 (FPO: [0,3,4])
> 8078aea4 8267842a 853aaa00 86c7b2ef 853aa838 hal!KfLowerIrql+0x58
> (FPO: [0,1,4])
> 8078aec0 8af7a837 853aaac0 00000000 8af7a634
> nt!KeSynchronizeExecution+0x4a
> 8078aee4 86c73309 01efa008 00000000 8078af10
> E1G60I32!E1000HandleInterrupt+0x139 (FPO: [4,0,4])
> 8078af20 86c1e9f4 853aaad4 003aaac0 00000000
> ndis!ndisMiniportDpc+0xe2 (FPO: [4,6,4])
> 8078af48 826a13b5 853aaad4 853aaac0 00000000
> ndis!ndisInterruptDpc+0xaf (FPO: [4,1,4])
> 8078afa4 826a1218 82762d20 85993548 00000000
> nt!KiExecuteAllDpcs+0xf9
> 8078aff4 826a09dc 8a5bfc78 00000000 00000000
> nt!KiRetireDpcList+0xd5
> 8078aff8 8a5bfc78 00000000 00000000 00000000
> nt!KiDispatchInterrupt+0x2c (FPO: [Uses EBP] [0,0,1])
> WARNING: Frame IP not in any known module. Following frames may be wrong.
> 826a09dc 00000000 0000001a 00d6850f bb830000 0x8a5bfc78
>
> -----------------------------------------------------------------------
>
> The only other process that showed anything NDIS related was our install
> helper application. It adds the LWF network component using code lifted
> from the DDK. Here are the threads for that process …
>
> -----------------------------------------------------------------------
>
> PROCESS 83fd7468 SessionId: 1 Cid: 02a4 Peb: 7ffd5000 ParentCid:
> 0b1c
> DirBase: 3ec34620 ObjectTable: 93cfb498 HandleCount: 235.
> Image: netcfg.exe
> VadRoot 857c8400 Vads 123 Clone 0 Private 712. Modified 174. Locked 0.
> DeviceMap 90334710
> Token a0147030
> ElapsedTime 00:01:36.640
> UserTime 00:00:00.000
> KernelTime 00:00:00.031
> QuotaPoolUsage[PagedPool] 0
> QuotaPoolUsage[NonPagedPool] 0
> Working Set Sizes (now,min,max) (2602, 50, 345) (10408KB, 200KB,
> 1380KB)
> PeakWorkingSetSize 2603
> VirtualSize 73 Mb
> PeakVirtualSize 73 Mb
> PageFaultCount 4897
> MemoryPriority BACKGROUND
> BasePriority 8
> CommitCharge 1087
> Job 83e5ba90
>
> THREAD 8564c4b8 Cid 02a4.0aac Teb: 7ffdf000 Win32Thread:
> fe996dd8 ???
> IRP List:
> 83ddc4d8: (0006,0094) Flags: 00060030 Mdl: 00000000
> 840a1cc0: (0006,01d8) Flags: 00060000 Mdl: 00000000
> Not impersonating
> DeviceMap 90334710
> Owning Process 83fd7468 Image: netcfg.exe
> Attached Process N/A Image: N/A
> Wait Start TickCount 33393 Ticks: 4578
> (0:00:01:11.531)
> Context Switch Count 698
> UserTime 00:00:00.093
> KernelTime 00:00:00.671
> Win32 Start Address 0x0100342b
> Stack Init 914b3fd0 Current 914b3810 Base 914b4000 Limit 914b1000
> Call 0
> Priority 11 BasePriority 8 UnusualBoost 0 ForegroundBoost 2
> IoPriority 2 PagePriority 5
> ChildEBP RetAddr Args to Child
> 914b3828 826a7b15 8564c4b8 00000000 82762d20 nt!KiSwapContext+0x26
> (FPO: [Uses EBP] [0,0,4])
> 914b3860 826a6403 8564c578 8564c4b8 914b3920 nt!KiSwapThread+0x266
> 914b3888 826a02cf 8564c4b8 8564c578 00000000
> nt!KiCommitThreadWait+0x1df
> 914b3900 86c916bb 914b3920 00000000 00000000
> nt!KeWaitForSingleObject+0x393
> 914b3948 8af7da31 00030d40 84e42110 84e420e0 ndis!NdisMSleep+0x55
> (FPO: [1,10,4])
> 914b3964 86c9132a 84efa008 914b3990 00000008
> E1G60I32!E1000Pause+0x33 (FPO: [2,1,4])
> 914b39a0 86c92573 00e420e0 00000008 84e420e0
> ndis!ndisPauseMiniport+0x190 (FPO: [2,8,4])
> 914b3a10 86c2a0fc 00e420e0 00000000 00000000
> ndis!ndisCloseMiniportBindingsForPause+0x1be (FPO: [2,21,4])
> 914b3b44 86ca2827 841aa5d0 00000000 84e420e0
> ndis!ndisAttachFilterToMiniport+0x298 (FPO: [3,70,4])
> 914b3b84 86c93950 858fac90 858fac98 00000000
> ndis!ndisHandleFilterAttachNotification+0x1a5 (FPO: [2,8,4])
> 914b3ba8 86c8e3b8 858fac98 00000000 83ddc4d8
> ndis!ndisHandleUModePnPOp+0x283 (FPO: [1,2,4])
> 914b3bdc 86c8e57e 83ddc4d8 8404c120 84c3b720
> ndis!ndisHandlePnPRequest+0x378 (FPO: [1,7,4])
> 914b3bfc 826754bc 84c3b720 83ddc4d8 83ddc4d8
> ndis!ndisDispatchRequest+0x8a (FPO: [2,2,4])
> 914b3c14 82876eee 8404c120 83ddc4d8 83ddc548 nt!IofCallDriver+0x63
> 914b3c34 82893cd1 84c3b720 8404c120 00000000
> nt!IopSynchronousServiceTail+0x1f8
> 914b3cd0 828964ac 84c3b720 83ddc4d8 00000000
> nt!IopXxxControlFile+0x6aa
> 914b3d04 8267c42a 000003dc 00000000 00000000
> nt!NtDeviceIoControlFile+0x2a
> 914b3d04 771664f4 000003dc 00000000 00000000
> nt!KiFastCallEntry+0x12a (FPO: [0,3] TrapFrame @ 914b3d34)
> WARNING: Frame IP not in any known module. Following frames may be wrong.
> 0006f484 00000000 00000000 00000000 00000000 0x771664f4
>
> THREAD 8597e8a8 Cid 02a4.0974 Teb: 7ffde000 Win32Thread:
> ffabc250 WAIT: (WrUserRequest) UserMode Non-Alertable
> 85881af8 SynchronizationEvent
> Not impersonating
> DeviceMap 90334710
> Owning Process 83fd7468 Image: netcfg.exe
> Attached Process N/A Image: N/A
> Wait Start TickCount 31928 Ticks: 6043
> (0:00:01:34.421)
> Context Switch Count 27
> UserTime 00:00:00.000
> KernelTime 00:00:00.062
> Win32 Start Address 0x010026a0
> Stack Init 93983fd0 Current 93983af8 Base 93984000 Limit 93981000
> Call 0
> Priority 12 BasePriority 8 UnusualBoost 0 ForegroundBoost 2
> IoPriority 2 PagePriority 5
> ChildEBP RetAddr Args to Child
> 93983b10 826a7b15 8597e8a8 82765f08 82762d20 nt!KiSwapContext+0x26
> (FPO: [Uses EBP] [0,0,4])
> 93983b48 826a6403 8597e968 8597e8a8 85881af8 nt!KiSwapThread+0x266
> 93983b70 826a02cf 8597e8a8 8597e968 00000000
> nt!KiCommitThreadWait+0x1df
> 93983be8 8f990d75 85881af8 0000000d 00000001
> nt!KeWaitForSingleObject+0x393
> 93983c44 8f990e10 000025ff 00000000 00000001
> win32k!xxxRealSleepThread+0x1d7 (FPO: [SEH])
> 93983c60 8f989a86 000025ff 00000000 00000001
> win32k!xxxSleepThread+0x2d (FPO: [3,0,0])
> 93983cb8 8f990e6b 93983ce8 000025ff 00000000
> win32k!xxxRealInternalGetMessage+0x4b2 (FPO: [SEH])
> 93983d1c 8267c42a 0034feb8 00000000 00000000
> win32k!NtUserGetMessage+0x3f (FPO: [SEH])
> 93983d1c 771664f4 0034feb8 00000000 00000000
> nt!KiFastCallEntry+0x12a (FPO: [0,3] TrapFrame @ 93983d34)
> WARNING: Frame IP not in any known module. Following frames may be wrong.
> 0034fe94 00000000 00000000 00000000 00000000 0x771664f4
>
> THREAD 83fb8198 Cid 02a4.0b50 Teb: 7ffdd000 Win32Thread:
> 00000000 ???
> Not impersonating
> DeviceMap 90334710
> Owning Process 83fd7468 Image: netcfg.exe
> Attached Process N/A Image: N/A
> Wait Start TickCount 34745 Ticks: 3226
> (0:00:00:50.406)
> Context Switch Count 89
> UserTime 00:00:00.000
> KernelTime 00:00:00.000
> Win32 Start Address 0x7714edfb
> Stack Init 938dffd0 Current 938df748 Base 938e0000 Limit 938dd000
> Call 0
> Priority 12 BasePriority 8 UnusualBoost 0 ForegroundBoost 2
> IoPriority 2 PagePriority 5
> ChildEBP RetAddr Args to Child
> 938df760 826a7b15 83fb8198 82765f08 82762d20 nt!KiSwapContext+0x26
> (FPO: [Uses EBP] [0,0,4])
> 938df798 826a6403 83e8ab58 83fb8198 841422b4 nt!KiSwapThread+0x266
> 938df7c0 826a26ef 83fb8198 84142008 00000000
> nt!KiCommitThreadWait+0x1df
> 938df93c 8286b625 0000001c 938dfa74 00000001
> nt!KeWaitForMultipleObjects+0x535
> 938dfbc8 8286b392 0000001c 938dfc64 00000001
> nt!ObpWaitForMultipleObjects+0x262
> 938dfd18 8267c42a 0000001c 0018afd0 00000001
> nt!NtWaitForMultipleObjects+0xcd
> 938dfd18 771664f4 0000001c 0018afd0 00000001
> nt!KiFastCallEntry+0x12a (FPO: [0,3] TrapFrame @ 938dfd34)
> WARNING: Frame IP not in any known module. Following frames may be wrong.
> 0067ff88 00000000 00000000 00000000 00000000 0x771664f4
>
> THREAD 8422fd48 Cid 02a4.0dd4 Teb: 7ffdc000 Win32Thread:
> 00000000 ???
> Not impersonating
> DeviceMap 90334710
> Owning Process 83fd7468 Image: netcfg.exe
> Attached Process N/A Image: N/A
> Wait Start TickCount 33393 Ticks: 4578
> (0:00:01:11.531)
> Context Switch Count 1
> UserTime 00:00:00.000
> KernelTime 00:00:00.000
> Win32 Start Address 0x753a7bbd
> Stack Init 938c3fd0 Current 938c3748 Base 938c4000 Limit 938c1000
> Call 0
> Priority 10 BasePriority 8 UnusualBoost 0 ForegroundBoost 2
> IoPriority 2 PagePriority 5
> ChildEBP RetAddr Args to Child
> 938c3760 826a7b15 8422fd48 82765f08 82762d20 nt!KiSwapContext+0x26
> (FPO: [Uses EBP] [0,0,4])
> 938c3798 826a6403 00000000 8422fd48 8422fe2c nt!KiSwapThread+0x266
> 938c37c0 826a26ef 8422fd48 8422fe08 00000045
> nt!KiCommitThreadWait+0x1df
> 938c393c 8286b625 00000001 938c3a74 00000001
> nt!KeWaitForMultipleObjects+0x535
> 938c3bc8 8286b392 00000001 938c3bf8 00000001
> nt!ObpWaitForMultipleObjects+0x262
> 938c3d18 8267c42a 00000001 008dfecc 00000001
> nt!NtWaitForMultipleObjects+0xcd
> 938c3d18 771664f4 00000001 008dfecc 00000001
> nt!KiFastCallEntry+0x12a (FPO: [0,3] TrapFrame @ 938c3d34)
> WARNING: Frame IP not in any known module. Following frames may be wrong.
> 008dff18 00000000 00000000 00000000 00000000 0x771664f4
>
> THREAD 841e0d48 Cid 02a4.0f20 Teb: 7ffdb000 Win32Thread:
> 00000000 WAIT: (WrQueue) UserMode Alertable
> 840258d8 QueueObject
> Not impersonating
> DeviceMap 90334710
> Owning Process 83fd7468 Image: netcfg.exe
> Attached Process N/A Image: N/A
> Wait Start TickCount 31877 Ticks: 6094
> (0:00:01:35.218)
> Context Switch Count 2
> UserTime 00:00:00.000
> KernelTime 00:00:00.000
> Win32 Start Address 0x7714d63e
> Stack Init 88bc0fd0 Current 88bc0b60 Base 88bc1000 Limit 88bbe000
> Call 0
> Priority 8 BasePriority 8 UnusualBoost 0 ForegroundBoost 0
> IoPriority 2 PagePriority 5
> ChildEBP RetAddr Args to Child
> 88bc0b78 826a7b15 841e0d48 82765f08 82762d20 nt!KiSwapContext+0x26
> (FPO: [Uses EBP] [0,0,4])
> 88bc0bb0 826a6403 841e0e08 841e0d48 840258d8 nt!KiSwapThread+0x266
> 88bc0bd8 826a766d 841e0d48 841e0e08 00000000
> nt!KiCommitThreadWait+0x1df
> 88bc0c38 8286a71d 840258d8 826eaf01 00000001
> nt!KeRemoveQueueEx+0x4f8
> 88bc0c90 826aace6 840258d8 88bc0cc8 88bc0cf0
> nt!IoRemoveIoCompletion+0x23
> 88bc0d24 8267c42a 00000260 0091fedc 0091ff88
> nt!NtWaitForWorkViaWorkerFactory+0x1a1
> 88bc0d24 771664f4 00000260 0091fedc 0091ff88
> nt!KiFastCallEntry+0x12a (FPO: [0,3] TrapFrame @ 88bc0d34)
> WARNING: Frame IP not in any known module. Following frames may be wrong.
> 0091ff88 00000000 00000000 00000000 00000000 0x771664f4
>
> THREAD 85875c90 Cid 02a4.07e4 Teb: 7ffda000 Win32Thread:
> 00000000 ???
> Not impersonating
> DeviceMap 90334710
> Owning Process 83fd7468 Image: netcfg.exe
> Attached Process N/A Image: N/A
> Wait Start TickCount 37449 Ticks: 522
> (0:00:00:08.156)
> Context Switch Count 2
> UserTime 00:00:00.000
> KernelTime 00:00:00.000
> Win32 Start Address 0x7714d63e
> Stack Init 88bf0fd0 Current 88bf0b60 Base 88bf1000 Limit 88bee000
> Call 0
> Priority 10 BasePriority 8 UnusualBoost 0 ForegroundBoost 2
> IoPriority 2 PagePriority 5
> ChildEBP RetAddr Args to Child
> 88bf0b78 826a7b15 85875c90 82765f08 82762d20 nt!KiSwapContext+0x26
> (FPO: [Uses EBP] [0,0,4])
> 88bf0bb0 826a6403 85875d50 85875c90 841bc1e8 nt!KiSwapThread+0x266
> 88bf0bd8 826a766d 85875c90 85875d50 00000047
> nt!KiCommitThreadWait+0x1df
> 88bf0c38 8286a71d 841bc1e8 826eaf01 00000001
> nt!KeRemoveQueueEx+0x4f8
> 88bf0c90 826aace6 841bc1e8 88bf0cc8 88bf0cf0
> nt!IoRemoveIoCompletion+0x23
> 88bf0d24 8267c42a 00000160 00f2fedc 00f2ff88
> nt!NtWaitForWorkViaWorkerFactory+0x1a1
> 88bf0d24 771664f4 00000160 00f2fedc 00f2ff88
> nt!KiFastCallEntry+0x12a (FPO: [0,3] TrapFrame @ 88bf0d34)
> WARNING: Frame IP not in any known module. Following frames may be wrong.
> 00f2ff88 00000000 00000000 00000000 00000000 0x771664f4
>
> -----------------------------------------------------------------------
>
> Could our installer application be doing something that actually locks up
> the system? I wouldn’t think that would be possible. It essentially just
> calls the HrInstallNetComponent function from component.cpp, an example I
> found in one of the DDKs. It appears to call SetupCopyOEMInf, then
> INetCfg::QueryNetCfgClass() using IID_INetCfgClassSetup and finally
> pncClassSetup->Install(). The only parameters I pass to the DDK source
> code is a class GUID_DEVCLASS_NETSERVICE, the inf file path and the inf
> component ID name.
>
> Is there another, better way to install a network filter service?
>
> -Matthew
>
> —
> NTDEV is sponsored by OSR
>
> 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

8


Could our installer application be doing something that actually locks
up the system? I wouldn’t think that would be possible. It essentially
just calls the HrInstallNetComponent function from component.cpp, an
example I found in one of the DDKs. It appears to call SetupCopyOEMInf,
then INetCfg::QueryNetCfgClass() using IID_INetCfgClassSetup and finally
pncClassSetup->Install(). The only parameters I pass to the DDK source
code is a class GUID_DEVCLASS_NETSERVICE, the inf file path and the inf
component ID name.

Is there another, better way to install a network filter service?


I think the NETCFG (SNETCFG) sample from the W2K DDK is a fine choice!

You can also create a DIFxAPP package with WIX pretty trivially and have an
MSI. Specify the DriverPackageType=Network in the INF. And no, (sadly),
DPINST.EXE will not work for some reason as it does not seem to provide all
of the correct mojo to the DIFxAPI needed for it to install a Network
component. But WIX is the greatest tool since the invention of the hammer
(IMHO). A recent posting to this list of a WIX installer for the Zen
drivers by James (search archives) shows just how straight forward that is.

The issue you seem to have come across is that while you installer has asked
nicely of NetCFG and NDIS to install your filter, some component in kernel
mode has wedged the system trying to complete the adapter ‘pause’ required
for the system to reach a state whereby an LWF can be inserted or removed
from the adapter stack. Your task now is to figure out why it is stuck.

You said that one core is pinned at 100% CPU - you can tell Windbg to set
the current CPU to be the one that is spinning and set break-points on
‘exit’ from whatever the wait reason is. A CPU bound wait is always going
to be at elevated IRQL and generally a spinlock. Turn on driver verifier
for the driver that is trying to acquire the lock. If it is your driver,
well, look for the possibility that you have tried to acquire the same lock
twice (a nice bugcheck when verifier is enabled).

Good Luck,
Dave Cattley

9

David R. Cattley wrote:

Hi David,

Thanks again for your response.

I think the NETCFG (SNETCFG) sample from the W2K DDK is a fine choice!

Fair enough. I was building our custom netcfg helper application using a
rather old version of the DDK. I thought maybe using a newer version of
the DDK to build the helper might improve the situation, but I can still
reproduce the problem consistently using the new binary.

You can also create a DIFxAPP package with WIX pretty trivially and have an
MSI. Specify the DriverPackageType=Network in the INF. And no, (sadly),
DPINST.EXE will not work for some reason as it does not seem to provide all
of the correct mojo to the DIFxAPI needed for it to install a Network
component. But WIX is the greatest tool since the invention of the hammer
(IMHO). A recent posting to this list of a WIX installer for the Zen
drivers by James (search archives) shows just how straight forward that is.

I use the DIFx library to “pre-install” the LWF driver package before
calling the netcfg function that adds our network service. Through a lot
of trial and error, I determined that DIFx did a more thorough job of
removing all the driver related bits after software uninstall so I stuck
with it even though it can’t actually install the component.

The issue you seem to have come across is that while you installer has asked
nicely of NetCFG and NDIS to install your filter, some component in kernel
mode has wedged the system trying to complete the adapter ‘pause’ required
for the system to reach a state whereby an LWF can be inserted or removed
from the adapter stack. Your task now is to figure out why it is stuck.

Hmmm. I am obviously out of my depth :slight_smile:

You said that one core is pinned at 100% CPU - you can tell Windbg to set
the current CPU to be the one that is spinning and set break-points on
‘exit’ from whatever the wait reason is. A CPU bound wait is always going
to be at elevated IRQL and generally a spinlock. Turn on driver verifier
for the driver that is trying to acquire the lock. If it is your driver,
well, look for the possibility that you have tried to acquire the same lock
twice (a nice bugcheck when verifier is enabled).

While the host computer is multi-core, the guest OS is only configured
to use a single core. I see one of my host computer cores pegged at 100%
CPU when the lockup occurs. I’m not sure what the guest operating system
thinks its single CPU utilization is. Its totally unresponsive.

If our driver was waiting indefinitely to acquire a spin lock, wouldn’t
I see that in a callstack somewhere? The only one I see is the netcfg
process calling installation function. If this is a lock related issue,
would it be a shared system lock of some sort? In other words, a lock
that both our LWF and the Intel miniport driver may have access to?

-Matthew

10

Any update on this Matthew? I’m hitting the same thing.

11

This problem goes away in VMWare 7. It is either a bug in VMWare 6.5 or the
6.5 Intel driver emulation.

Thomas F. Divine

From:
Sent: Tuesday, November 24, 2009 10:20 AM
To: “Windows System Software Devs Interest List”
Subject: RE:[ntdev] NDIS Related System Lock on VMware / Windows 7

> Any update on this Matthew? I’m hitting the same thing.
>
> —
> NTDEV is sponsored by OSR
>
> 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