NETIO.SYS & SYMTDIV.SYS BSOD on Win7 RTM with NAV 2010

Please assist.

 

I am experiencing BSOD after installing NAV 2010 on Windows 7 RTM. System experienced same BSOD during the public beta and now same issue with the NAV 2010 final release retail version.

 

Note, the BETA version was uninstalled entirely, all traces removed from the registry, all folders removed, and even ran the Norton Uninstall Tool to get anything left behind.

 

System has been running w/ no AV for SEVERAL days 24/7 w/o any issues. Once the retail release came out I decided to give it another chance and purchased it online w/ a 2 year subscription. It has been running for 2 days straight w/o any problems until last night when the system crashed on me.

 

--------------------------------------- 

System Specs:

---------------------------------------

 

Motherboard: ASUS P6T7 WS Supercomputer LGA 1366 Intel X58

Processor: Intel Core i7-975 Extreme Edition Bloomfield 3.33GHz LGA 1366 130W Quad-Core Processor

Memory Bank 1: CORSAIR DOMINATOR-GT 6GB (3 x 2GB) 240-Pin DDR3 SDRAM DDR3 1866 (PC3 15000) 

Memory Bank 2: CORSAIR DOMINATOR-GT 6GB (3 x 2GB) 240-Pin DDR3 SDRAM DDR3 1866 (PC3 15000)

     Above Memory Total: 12GB

Video Card: ASUS ENGTX295/2DI/1792MD3/A GeForce GTX 295 1792MB

HDD 1 & 2 in RAID 1 Config for C Drive: WD VelociRaptor 150GB SATA Hard Drive 10000rpm

HDD 3 & 4 in RAID 1 Config for D Drive: WD RE3 Enterprise 1 TB SATA Hard Drive 7200rpm

 

Note: Processor is not overclocked and memory is running at the XMP profile spec of 1.65v & 1866mhz.

Note 2: Memory test performed several times, no issues with memory detected.

Note 3: Windows 7 RTM is a clean install.

 

--------------------------------------- 

MEMORY.DMP

--------------------------------------- 

 

WARNING: Whitespace at start of path element

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


Loading Dump File [C:\Users\Kevin\Desktop\MEMORY DUMP\20090912_1248\MEMORY.DMP]
Kernel Summary Dump File: Only kernel address space is available

WARNING: Whitespace at start of path element
Symbol search path is:  http://msdl.microsoft.com/download/symbols
Executable search path is:
Windows 7 Kernel Version 7600 MP (8 procs) Free x64
Product: WinNt, suite: TerminalServer SingleUserTS
Built by: 7600.16385.amd64fre.win7_rtm.090713-1255
Machine Name:
Kernel base = 0xfffff800`02c61000 PsLoadedModuleList = 0xfffff800`02e9ee50
Debug session time: Sat Sep 12 12:46:34.954 2009 (GMT-4)
System Uptime: 0 days 0:48:30.844
Loading Kernel Symbols
...............................................................
................................................................
.................................................
Loading User Symbols

Loading unloaded module list
......
*******************************************************************************
*                                                                             *
*                        Bugcheck Analysis                                    *
*                                                                             *
*******************************************************************************

Use !analyze -v to get detailed debugging information.

BugCheck 7F, {8, 80050033, 6f8, fffff80002cd88b6}

*** ERROR: Module load completed but symbols could not be loaded for SYMTDIV.SYS
Probably caused by : NETIO.SYS ( NETIO!CompareSecurityContexts+6a )

Followup: MachineOwner
---------

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

UNEXPECTED_KERNEL_MODE_TRAP (7f)
This means a trap occurred in kernel mode, and it's a trap of a kind
that the kernel isn't allowed to have/catch (bound trap) or that
is always instant death (double fault).  The first number in the
bugcheck params is the number of the trap (8 = double fault, etc)
Consult an Intel x86 family manual to learn more about what these
traps are. Here is a *portion* of those codes:
If kv shows a taskGate
        use .tss on the part before the colon, then kv.
Else if kv shows a trapframe
        use .trap on that value
Else
        .trap on the appropriate frame will show where the trap was taken
        (on x86, this will be the ebp that goes with the procedure KiTrap)
Endif
kb will then show the corrected stack.
Arguments:
Arg1: 0000000000000008, EXCEPTION_DOUBLE_FAULT
Arg2: 0000000080050033
Arg3: 00000000000006f8
Arg4: fffff80002cd88b6

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


BUGCHECK_STR:  0x7f_8

DEFAULT_BUCKET_ID:  VISTA_DRIVER_FAULT

PROCESS_NAME:  System

CURRENT_IRQL:  2

LAST_CONTROL_TRANSFER:  from fffff80002cd2469 to fffff80002cd2f00

STACK_TEXT: 
<<Note, I removed Stacked Text to fit character limit on this post. I can post it seperately if needed>>
STACK_COMMAND:  kb

FOLLOWUP_IP:
NETIO!CompareSecurityContexts+6a
fffff880`0198bc5a 448b442470      mov     r8d,dword ptr [rsp+70h]

SYMBOL_STACK_INDEX:  6

SYMBOL_NAME:  NETIO!CompareSecurityContexts+6a

FOLLOWUP_NAME:  MachineOwner

MODULE_NAME: NETIO

IMAGE_NAME:  NETIO.SYS

DEBUG_FLR_IMAGE_TIMESTAMP:  4a5bc18a

FAILURE_BUCKET_ID:  X64_0x7f_8_NETIO!CompareSecurityContexts+6a

BUCKET_ID:  X64_0x7f_8_NETIO!CompareSecurityContexts+6a

Followup: MachineOwner
---------

3: kd> lmvm NETIO
start             end                 module name
fffff880`01985000 fffff880`019e5000   NETIO      (pdb symbols)          C:\Program Files\Debugging Tools for Windows (x64)\sym\netio.pdb\4ACD68B3A9824AAAB3C53C0077FC611F2\netio.pdb
    Loaded symbol image file: NETIO.SYS
    Image path: \SystemRoot\system32\drivers\NETIO.SYS
    Image name: NETIO.SYS
    Timestamp:        Mon Jul 13 19:21:46 2009 (4A5BC18A)
    CheckSum:         0005F36C
    ImageSize:        00060000
    Translations:     0000.04b0 0000.04e4 0409.04b0 0409.04e4

Thank you Simon. I have uploaded the file.

 

Also forgot to mention this is the 64-bit version of Windows 7 RTM I have installed. Thanks again.

Thanks.  I passed your info along to the appropriate team.

 

-Simon

Hi kevin7,

 

Just to let you know, we are investigating this

problem together with Microsoft.

 

We’ll let you know when we learn something.

 

Thanks,

Simon

Thank you for staying on top of this.

Please assist.

 

I am experiencing BSOD after installing NAV 2010 on Windows 7 RTM. System experienced same BSOD during the public beta and now same issue with the NAV 2010 final release retail version.

 

Note, the BETA version was uninstalled entirely, all traces removed from the registry, all folders removed, and even ran the Norton Uninstall Tool to get anything left behind.

 

System has been running w/ no AV for SEVERAL days 24/7 w/o any issues. Once the retail release came out I decided to give it another chance and purchased it online w/ a 2 year subscription. It has been running for 2 days straight w/o any problems until last night when the system crashed on me.

 

--------------------------------------- 

System Specs:

---------------------------------------

 

Motherboard: ASUS P6T7 WS Supercomputer LGA 1366 Intel X58

Processor: Intel Core i7-975 Extreme Edition Bloomfield 3.33GHz LGA 1366 130W Quad-Core Processor

Memory Bank 1: CORSAIR DOMINATOR-GT 6GB (3 x 2GB) 240-Pin DDR3 SDRAM DDR3 1866 (PC3 15000) 

Memory Bank 2: CORSAIR DOMINATOR-GT 6GB (3 x 2GB) 240-Pin DDR3 SDRAM DDR3 1866 (PC3 15000)

     Above Memory Total: 12GB

Video Card: ASUS ENGTX295/2DI/1792MD3/A GeForce GTX 295 1792MB

HDD 1 & 2 in RAID 1 Config for C Drive: WD VelociRaptor 150GB SATA Hard Drive 10000rpm

HDD 3 & 4 in RAID 1 Config for D Drive: WD RE3 Enterprise 1 TB SATA Hard Drive 7200rpm

 

Note: Processor is not overclocked and memory is running at the XMP profile spec of 1.65v & 1866mhz.

Note 2: Memory test performed several times, no issues with memory detected.

Note 3: Windows 7 RTM is a clean install.

 

--------------------------------------- 

MEMORY.DMP

--------------------------------------- 

 

WARNING: Whitespace at start of path element

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


Loading Dump File [C:\Users\Kevin\Desktop\MEMORY DUMP\20090912_1248\MEMORY.DMP]
Kernel Summary Dump File: Only kernel address space is available

WARNING: Whitespace at start of path element
Symbol search path is:  http://msdl.microsoft.com/download/symbols
Executable search path is:
Windows 7 Kernel Version 7600 MP (8 procs) Free x64
Product: WinNt, suite: TerminalServer SingleUserTS
Built by: 7600.16385.amd64fre.win7_rtm.090713-1255
Machine Name:
Kernel base = 0xfffff800`02c61000 PsLoadedModuleList = 0xfffff800`02e9ee50
Debug session time: Sat Sep 12 12:46:34.954 2009 (GMT-4)
System Uptime: 0 days 0:48:30.844
Loading Kernel Symbols
...............................................................
................................................................
.................................................
Loading User Symbols

Loading unloaded module list
......
*******************************************************************************
*                                                                             *
*                        Bugcheck Analysis                                    *
*                                                                             *
*******************************************************************************

Use !analyze -v to get detailed debugging information.

BugCheck 7F, {8, 80050033, 6f8, fffff80002cd88b6}

*** ERROR: Module load completed but symbols could not be loaded for SYMTDIV.SYS
Probably caused by : NETIO.SYS ( NETIO!CompareSecurityContexts+6a )

Followup: MachineOwner
---------

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

UNEXPECTED_KERNEL_MODE_TRAP (7f)
This means a trap occurred in kernel mode, and it's a trap of a kind
that the kernel isn't allowed to have/catch (bound trap) or that
is always instant death (double fault).  The first number in the
bugcheck params is the number of the trap (8 = double fault, etc)
Consult an Intel x86 family manual to learn more about what these
traps are. Here is a *portion* of those codes:
If kv shows a taskGate
        use .tss on the part before the colon, then kv.
Else if kv shows a trapframe
        use .trap on that value
Else
        .trap on the appropriate frame will show where the trap was taken
        (on x86, this will be the ebp that goes with the procedure KiTrap)
Endif
kb will then show the corrected stack.
Arguments:
Arg1: 0000000000000008, EXCEPTION_DOUBLE_FAULT
Arg2: 0000000080050033
Arg3: 00000000000006f8
Arg4: fffff80002cd88b6

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


BUGCHECK_STR:  0x7f_8

DEFAULT_BUCKET_ID:  VISTA_DRIVER_FAULT

PROCESS_NAME:  System

CURRENT_IRQL:  2

LAST_CONTROL_TRANSFER:  from fffff80002cd2469 to fffff80002cd2f00

STACK_TEXT: 
<<Note, I removed Stacked Text to fit character limit on this post. I can post it seperately if needed>>
STACK_COMMAND:  kb

FOLLOWUP_IP:
NETIO!CompareSecurityContexts+6a
fffff880`0198bc5a 448b442470      mov     r8d,dword ptr [rsp+70h]

SYMBOL_STACK_INDEX:  6

SYMBOL_NAME:  NETIO!CompareSecurityContexts+6a

FOLLOWUP_NAME:  MachineOwner

MODULE_NAME: NETIO

IMAGE_NAME:  NETIO.SYS

DEBUG_FLR_IMAGE_TIMESTAMP:  4a5bc18a

FAILURE_BUCKET_ID:  X64_0x7f_8_NETIO!CompareSecurityContexts+6a

BUCKET_ID:  X64_0x7f_8_NETIO!CompareSecurityContexts+6a

Followup: MachineOwner
---------

3: kd> lmvm NETIO
start             end                 module name
fffff880`01985000 fffff880`019e5000   NETIO      (pdb symbols)          C:\Program Files\Debugging Tools for Windows (x64)\sym\netio.pdb\4ACD68B3A9824AAAB3C53C0077FC611F2\netio.pdb
    Loaded symbol image file: NETIO.SYS
    Image path: \SystemRoot\system32\drivers\NETIO.SYS
    Image name: NETIO.SYS
    Timestamp:        Mon Jul 13 19:21:46 2009 (4A5BC18A)
    CheckSum:         0005F36C
    ImageSize:        00060000
    Translations:     0000.04b0 0000.04e4 0409.04b0 0409.04e4

Kevin,

 

Bugcheck 7F is due to a kernel stack overflow.

 

Microsoft is currently evaluating this problem for a possible fix in the future.

In the mean time, you can mitigate the crash by disabling NetBIOS over TCP.

 

Here are two support articles which explain how to do this both on the client side as well as the DHCP server (should this be a business network) http://support.microsoft.com/kb/299977/http://support.microsoft.com/kb/313314/ 

 

Thanks for the update. Unfortunately I have moved on to a different AV product which is not having any issues. Sounds to me like a compatibility issue with NAV and not entirely Microsofts fault.

 

I will use NAV 2010 on my other machines.

 

Thanks again.

Kevin,

Just for your information:

 

This is a part of an anlysis provided by Microsoft:

 

 

Anything over 10% is considered worth investigating.   Module               Stack Usage       Percentagefwpkclnt                176                         1SYMTDIV              2240                        9Rt64win7               320                         1ndis                         1488                        6tdx                           768                         3tcpip                      12544                    52netbt                       912                         4nt                             3248                      13NETIO                    2656                      11 ********* WARNING WARNING ********* High stack usage by tcpip52% of the stack is used by this moduleHigh stack usage by NETIO

11% of the stack is used by this module

 It's easy to see how the stack consumed by SymTDIv is enough to push this thread over the limit.It is not reasonable to expect third party filters to function with almost no stack remaining. Sorry to hear that you cannot use Norton on this system.I'll let you know if we learn anything new about the problem. - Pete 

Reposting for correct formating

 

Anything over 10% is considered worth investigating.

 

Module               Stack Usage       Percentage

fwpkclnt                176                         1

SYMTDIV              2240                        9

Rt64win7               320                         1

ndis                         1488                        6

tdx                           768                         3

tcpip                      12544                    52

netbt                       912                         4

nt                             3248                      13

NETIO                    2656                      11

 

 

 ********* WARNING WARNING ********* High stack usage by tcpip

52% of the stack is used by this module

High stack usage by NETIO

11% of the stack is used by this module

 

It's easy to see how the stack consumed by SymTDIv is enough to push this thread over the limit.It is not reasonable to expect third party filters to function with almost no stack remaining. Sorry to hear that you cannot use Norton on this system.I'll let you know if we learn anything new about the problem.

- Pete 

 

<<Edit: Fixed posting error>>

 

 

Message Edited by TomV on 10-13-2009 05:19 AM

Thank you Peter for the additional info. Could it be NAV causing the high stack in TCP/IP? Just a thought but thanks again for the additional info. It will be very helpful next time this happens.


Kevin7 wrote:
Thank you Peter for the additional info. Could it be NAV causing the high stack in TCP/IP? Just a thought but thanks again for the additional info. It will be very helpful next time this happens.

No, SYMTDIV represents the NAV contribution to the stack usage. It appears that Microsoft wrote their drivers to use some very large amount of stack space at certain moments leaving other network filters very little space to work within at the same moment.


Peter_Linhardt wrote:

Kevin,

 

Bugcheck 7F is due to a kernel stack overflow.

 

Microsoft is currently evaluating this problem for a possible fix in the future.

In the mean time, you can mitigate the crash by disabling NetBIOS over TCP.

 

Here are two support articles which explain how to do this both on the client side as well as the DHCP server (should this be a business network) http://support.microsoft.com/kb/299977/http://support.microsoft.com/kb/313314/ 

 


This worked for me and I am back into business!  I am glad that this worked!  I hope this gets fixed soon by who ever is responsible for the cause of BSOD.  

 

Nate

I have same Issue with my Windows 7 Utimate OEM Verison with NIS 2010.  Many day I use live chat for help. Tech support tried many different method. Many time got BSOD. I googled for help and found this Forum. I will try disable NETBIOS over TCP/IP. I reinstall NIS 2010 back on. I dont understand why Tech support not know about this.

 

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


Loading Dump File [C:\Windows\MEMORY.DMP]
Kernel Summary Dump File: Only kernel address space is available

Symbol search path is: C:\Windows\Symbol;SRV*c:\websymbols*http://msdl.microsoft.com/download/symbols
Executable search path is:
Windows 7 Kernel Version 7600 MP (4 procs) Free x64
Product: WinNt, suite: TerminalServer SingleUserTS
Built by: 7600.16385.amd64fre.win7_rtm.090713-1255
Machine Name:
Kernel base = 0xfffff800`02a5b000 PsLoadedModuleList = 0xfffff800`02c98e50
Debug session time: Thu Nov 12 20:07:51.957 2009 (GMT-5)
System Uptime: 0 days 8:40:36.720
Loading Kernel Symbols
...............................................................
................................................................
.............................
Loading User Symbols

Loading unloaded module list
...............
*******************************************************************************
*                                                                             *
*                        Bugcheck Analysis                                    *
*                                                                             *
*******************************************************************************

Use !analyze -v to get detailed debugging information.

BugCheck 7F, {8, 80050031, 6f8, fffff80002aa840f}

*** ERROR: Module load completed but symbols could not be loaded for SYMTDIV.SYS
Probably caused by : NETIO.SYS ( NETIO!CompareSecurityContexts+6a )

Followup: MachineOwner
---------

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

UNEXPECTED_KERNEL_MODE_TRAP (7f)
This means a trap occurred in kernel mode, and it's a trap of a kind
that the kernel isn't allowed to have/catch (bound trap) or that
is always instant death (double fault).  The first number in the
bugcheck params is the number of the trap (8 = double fault, etc)
Consult an Intel x86 family manual to learn more about what these
traps are. Here is a *portion* of those codes:
If kv shows a taskGate
        use .tss on the part before the colon, then kv.
Else if kv shows a trapframe
        use .trap on that value
Else
        .trap on the appropriate frame will show where the trap was taken
        (on x86, this will be the ebp that goes with the procedure KiTrap)
Endif
kb will then show the corrected stack.
Arguments:
Arg1: 0000000000000008, EXCEPTION_DOUBLE_FAULT
Arg2: 0000000080050031
Arg3: 00000000000006f8
Arg4: fffff80002aa840f

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


BUGCHECK_STR:  0x7f_8

DEFAULT_BUCKET_ID:  VISTA_DRIVER_FAULT

PROCESS_NAME:  System

CURRENT_IRQL:  2

LAST_CONTROL_TRANSFER:  from fffff80002acc469 to fffff80002accf00

STACK_TEXT: 
fffff800`00ba4d28 fffff800`02acc469 : 00000000`0000007f 00000000`00000008 00000000`80050031 00000000`000006f8 : nt!KeBugCheckEx
fffff800`00ba4d30 fffff800`02aca932 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KiBugCheckDispatch+0x69
fffff800`00ba4e70 fffff800`02aa840f : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KiDoubleFaultAbort+0xb2
fffff880`0a081ff0 fffff800`02a9569c : fffff880`0a0820d0 fffffa80`088b67c8 00000000`00000000 00000000`00000000 : nt!RtlSidHashInitialize+0x2f
fffff880`0a082020 fffff800`02a957df : fffffa80`088b67c8 00000000`00000001 00000000`00000000 00000000`00000000 : nt!SepTokenFromAccessInformation+0xbc
fffff880`0a082050 fffff880`01606c5a : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!SeAccessCheckFromState+0x9f
fffff880`0a082740 fffff880`0160494f : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : NETIO!CompareSecurityContexts+0x6a
fffff880`0a0827b0 fffff880`016069b5 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : NETIO!MatchValues+0xef
fffff880`0a082800 fffff880`01606845 : fffffa80`0af49110 fffffa80`08aa7620 fffff880`0a082a28 fffff880`0a083160 : NETIO!FilterMatch+0x95
fffff880`0a082850 fffff880`01607ccb : 00000000`00000000 00000000`00000000 fffff880`0a083160 fffff880`0a082a10 : NETIO!IndexListClassify+0x69
fffff880`0a0828d0 fffff880`0183e4d0 : fffff880`0a083160 fffff880`0a082da8 fffff880`0a083ae0 fffffa80`0df18d50 : NETIO!KfdClassify+0xa4e
fffff880`0a082c40 fffff880`0183777e : fffff880`01946690 00000000`00000000 fffffa80`0ddff9c0 00000000`00000000 : tcpip!WfpAleClassify+0x50
fffff880`0a082c80 fffff880`01836c15 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : tcpip!WfpAlepAuthorizeSend+0x94e
fffff880`0a083390 fffff880`0183a956 : 00000000`00000000 00000000`00000000 00000000`00000011 00000000`00000000 : tcpip!WfpAleAuthorizeSend+0x325
fffff880`0a083660 fffff880`0183d6a4 : 00000000`00000000 fffff880`0a083a98 fffff880`0a083aa0 00000000`00000000 : tcpip!WfpAleConnectAcceptIndicate+0x106
fffff880`0a083750 fffff880`01835f59 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000008 : tcpip!ProcessALEForTransportPacket+0x664
fffff880`0a0839c0 fffff880`01862bf6 : 00000000`00000000 fffffa80`0af80002 fffffa80`0b9b8900 fffffa80`4d438900 : tcpip!WfpProcessOutTransportStackIndication+0x329
fffff880`0a083b90 fffff880`01867a7e : fffffa80`0b9bd2a0 fffff880`01602804 fffff880`0196c9a0 fffffa80`0ddff9c0 : tcpip!IppSendDatagramsCommon+0x526
fffff880`0a083e60 fffff880`01834cf8 : fffffa80`0ddff9c0 fffffa80`0df18d50 fffffa80`0df18d50 fffffa80`0b9bd2a0 : tcpip!IpNlpSendDatagrams+0x3e
fffff880`0a083ea0 fffff880`0183526d : fffffa80`0b61ba80 fffffa80`0b9d4200 fffff880`0a0847f0 00000000`00000000 : tcpip!UdpSendMessagesOnPathCreation+0x688
fffff880`0a084220 fffff880`01834ef5 : fffff880`0a084750 fffffa80`0a8c8900 00000000`00000001 00000000`0000000d : tcpip!UdpSendMessages+0x35d
fffff880`0a084610 fffff800`02adc64a : 00000000`00000003 00000000`00000001 00000000`00000003 00000000`00000000 : tcpip!UdpTlProviderSendMessagesCalloutRoutine+0x15
fffff880`0a084640 fffff880`018354b8 : fffff880`01834ee0 fffff880`0a084750 fffffa80`0b922a02 fffff880`040a7a00 : nt!KeExpandKernelStackAndCalloutEx+0xda
fffff880`0a084720 fffff880`01a16f45 : fffffa80`08748170 fffffa80`0b553190 fffffa80`0cb642a0 fffffa80`095befde : tcpip!UdpTlProviderSendMessages+0x78
fffff880`0a0847a0 fffff880`01a16ff2 : fffffa80`0b922a02 00000000`00000000 fffffa80`07a8b128 fffffa80`07a8b170 : tdx!TdxSendDatagramTransportAddress+0x2f5
fffff880`0a084880 fffff880`0406ba18 : fffffa80`0d7a4b20 00000000`000000c8 fffffa80`07766c30 fffffa80`07a8b010 : tdx!TdxTdiDispatchInternalDeviceControl+0x52
fffff880`0a0848b0 fffff880`04088b13 : fffffa80`0ba29bf4 fffffa80`0b922a60 00000000`00000064 fffffa80`0b922a60 : SYMTDIV+0x7a18
fffff880`0a084910 fffff880`04089000 : fffffa80`0b922a60 00000000`00000064 fffffa80`0b922a60 fffffa80`0b922a60 : SYMTDIV+0x24b13
fffff880`0a084950 fffff880`04088f94 : fffffa80`0b922a60 fffffa80`0b922a60 00000000`00000000 00000000`00000065 : SYMTDIV+0x25000
fffff880`0a0849a0 fffff880`04088f94 : 00000000`00000000 fffffa80`0b922a60 00000000`00000000 00000000`00000064 : SYMTDIV+0x24f94
fffff880`0a0849f0 fffff880`0406bdd7 : 00000000`00000000 00000000`00000000 fffffa80`0d7a4b20 fffff880`0a084b38 : SYMTDIV+0x24f94
fffff880`0a084a40 fffff880`04081a9a : fffffa80`0d7a4b20 fffffa80`07a8b170 fffffa80`07a8b010 00000000`c000009a : SYMTDIV+0x7dd7
fffff880`0a084ae0 fffff880`0419c542 : 00000000`00000000 fffffa80`00000001 fffffa80`07a8b010 fffffa80`07a8b010 : SYMTDIV+0x1da9a
fffff880`0a084b30 fffff880`0419cf61 : fffffa80`095befa8 fffffa80`095befa8 fffffa80`0cab15a0 fffff880`0a084c30 : netbt!TdiSendDatagram+0x187
fffff880`0a084ba0 fffff880`041a9329 : fffffa80`0e7f7f50 fffffa80`095bedf0 00000000`00000021 00000000`0000003e : netbt!UdpSendDatagram+0x1b1
fffff880`0a084c30 fffff880`041aa992 : fffffa80`08d7ed01 fffffa80`0e7f7f50 00000000`00000000 fffffa80`0ba20089 : netbt!UdpSendResponse+0x4e0
fffff880`0a084cb0 fffff880`041a6bd5 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : netbt!CheckRegistrationFromNet+0x223
fffff880`0a084d80 fffff880`0419bb47 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : netbt!NameSrvHndlrNotOs+0xad
fffff880`0a084dc0 fffff880`0406b43c : fffff880`0a085080 fffffa80`0cb642a0 fffffa80`0ba29bf4 00000000`00000044 : netbt!TdiRcvNameSrvHandler+0x367
fffff880`0a084e60 fffff880`01a15325 : fffffa80`0b9ee4a0 fffffa80`091a0002 fffff880`0a0851d8 fffffa80`091adb90 : SYMTDIV+0x743c
fffff880`0a084f70 fffff880`018403c5 : fffffa80`091adb90 00000000`00000000 fffffa80`091adb90 fffffa80`091adb90 : tdx!TdxEventReceiveMessagesTransportAddress+0x315
fffff880`0a085160 fffff880`018408d4 : fffffa80`00000000 fffffa80`091adb90 00000000`00000000 fffffa80`08d7ed22 : tcpip!UdpDeliverDatagrams+0x155
fffff880`0a0852f0 fffff880`0185c427 : fffffa80`0877d8c0 00000000`00000000 00000000`00000000 00000000`00000000 : tcpip!UdpReceiveDatagrams+0x324
fffff880`0a0853e0 fffff880`0185c499 : fffff880`0a085560 fffff880`0196c9a0 fffff880`0a085570 fffffa80`0872de20 : tcpip!IppDeliverListToProtocol+0xf7
fffff880`0a0854a0 fffff880`0185c990 : fffff880`0196c9a0 fffffa80`0c0cbb00 00000000`00000011 fffff880`0a085560 : tcpip!IppProcessDeliverList+0x59
fffff880`0a085510 fffff880`0185b821 : fffffa80`ff01a8c0 fffffa80`0889d138 fffff880`0196c9a0 00000000`07145101 : tcpip!IppReceiveHeaderBatch+0x231
fffff880`0a0855f0 fffff880`01935592 : fffffa80`0a6ddce0 00000000`00000000 fffffa80`07145101 fffffa80`00000001 : tcpip!IpFlcReceivePackets+0x651
fffff880`0a0857f0 fffff880`017b3afa : fffffa80`0912a002 fffffa80`0912a010 00000000`00000002 00000000`00000000 : tcpip!IppInspectInjectReceive+0xf2
fffff880`0a085830 fffff880`040ab318 : fffffa80`09514880 00000000`00000002 fffff880`ffffff00 fffffa80`077511e0 : fwpkclnt!FwpsInjectTransportReceiveAsync0+0x256
fffff880`0a0858e0 fffff880`040a8ef0 : fffffa80`0c1ea6d0 00000000`00000000 fffff880`0a085d50 fffffa80`0c1ea6d0 : SYMTDIV+0x47318
fffff880`0a085970 fffff880`040a5a1f : fffffa80`0c1ea6d0 00000000`00000000 fffff880`0a085d50 fffffa80`0c1ea6d0 : SYMTDIV+0x44ef0
fffff880`0a0859d0 fffff880`040a4ee5 : fffffa80`07145110 00000000`000000c8 00000000`00000000 fffff880`0a085d50 : SYMTDIV+0x41a1f
fffff880`0a085a00 fffff880`04096f50 : fffff880`0a085d50 fffffa80`095965e0 fffff880`0a085af0 fffffa80`00000000 : SYMTDIV+0x40ee5
fffff880`0a085a50 fffff880`040a8b81 : fffffa80`077511e0 fffff880`040ad573 00000000`00000002 00000000`00000000 : SYMTDIV+0x32f50
fffff880`0a085b60 fffff880`040ad92b : 00000000`00000000 fffff880`0a085d10 fffff880`0a085d50 00000000`00000002 : SYMTDIV+0x44b81
fffff880`0a085bc0 fffff880`040a95c8 : fffff880`0a086070 fffff880`0a086590 fffff880`0a086590 fffff880`040c1130 : SYMTDIV+0x4992b
fffff880`0a085c60 fffff880`0161d57f : 00000000`00000000 fffffa80`08745b50 fffffa80`08745b50 00000000`00000000 : SYMTDIV+0x455c8
fffff880`0a085f00 fffff880`01606619 : 00000000`0000000c fffff880`0a086590 fffffa80`089dcca8 fffffa80`0aacfc80 : NETIO! ?? ::FNODOBFM::`string'+0x7267
fffff880`0a086020 fffff880`01607bb1 : fffff880`0a08000c fffff880`0a086590 fffffa80`08745b50 fffff880`00000000 : NETIO!ArbitrateAndEnforce+0x2a9
fffff880`0a0860f0 fffff880`0182482e : 00000000`0000000c fffff880`0a086590 00000000`00000001 fffffa80`0aacfc80 : NETIO!KfdClassify+0x934
fffff880`0a086460 fffff880`0183ed8d : fffffa80`0aacfc80 fffffa80`08745b50 fffffa80`089dcc50 fffffa80`08748900 : tcpip!ProcessInboundTransportLayerClassify+0x21e
fffff880`0a086680 fffff880`0186d861 : fffffa80`00000011 fffffa80`0e150002 fffffa80`08898900 00000000`00008900 : tcpip!WfpProcessInTransportStackIndication+0x81d
fffff880`0a0869f0 fffff880`0183ff93 : fffffa80`0e150ec0 fffffa80`08788820 00000000`00000000 fffffa80`0889d000 : tcpip!InetInspectReceiveDatagram+0x121
fffff880`0a086a90 fffff880`01840345 : fffffa80`0e150ec0 00000000`00000000 00000000`00000001 00000000`00000000 : tcpip!UdpBeginMessageIndication+0x83
fffff880`0a086be0 fffff880`018408d4 : fffffa80`00000000 fffffa80`0e150ec0 00000000`00000000 fffffa80`0ac1f4a2 : tcpip!UdpDeliverDatagrams+0xd5
fffff880`0a086d70 fffff880`0185c427 : fffffa80`0877d8c0 00000000`00000000 00000000`00000000 00000000`00000000 : tcpip!UdpReceiveDatagrams+0x324
fffff880`0a086e60 fffff880`0185c499 : fffff880`0a086fe0 fffff880`0196c9a0 fffff880`0a086ff0 fffffa80`0872de20 : tcpip!IppDeliverListToProtocol+0xf7
fffff880`0a086f20 fffff880`0185c990 : fffff880`0196c9a0 fffffa80`0aacfdb0 00000000`00000011 fffff880`0a086fe0 : tcpip!IppProcessDeliverList+0x59
fffff880`0a086f90 fffff880`0185b821 : 00000000`ff01a8c0 fffffa80`0889d000 fffff880`0196c9a0 00000000`0a8c7801 : tcpip!IppReceiveHeaderBatch+0x231
fffff880`0a087070 fffff880`0185a272 : fffffa80`0a8c1880 00000000`00000000 fffffa80`0a8c7801 00000000`00000001 : tcpip!IpFlcReceivePackets+0x651
fffff880`0a087270 fffff880`018736ba : fffffa80`0a8c7820 fffff880`0a0873a0 fffffa80`0a8c7820 fffffa80`0aab0000 : tcpip!FlpReceiveNonPreValidatedNetBufferListChain+0x2b2
fffff880`0a087350 fffff800`02adc64a : fffffa80`0aacfc80 fffff880`0a082000 00000000`00004800 00000000`00000000 : tcpip!FlReceiveNetBufferListChainCalloutRoutine+0xda
fffff880`0a0873a0 fffff880`018730e2 : fffff880`018735e0 fffff880`0a0874b0 00000000`00000002 00000001`00000001 : nt!KeExpandKernelStackAndCalloutEx+0xda
fffff880`0a087480 fffff880`017760eb : fffffa80`0a8d6010 00000000`00000000 fffffa80`0949e1a0 fffff880`10d31f5c : tcpip!FlReceiveNetBufferListChain+0xb2
fffff880`0a0874f0 fffff880`0173ffc6 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : ndis!ndisMIndicateNetBufferListsToOpen+0xdb


STACK_COMMAND:  kb

FOLLOWUP_IP:
NETIO!CompareSecurityContexts+6a
fffff880`01606c5a 448b442470      mov     r8d,dword ptr [rsp+70h]

SYMBOL_STACK_INDEX:  6

SYMBOL_NAME:  NETIO!CompareSecurityContexts+6a

FOLLOWUP_NAME:  MachineOwner

MODULE_NAME: NETIO

IMAGE_NAME:  NETIO.SYS

DEBUG_FLR_IMAGE_TIMESTAMP:  4a5bc18a

FAILURE_BUCKET_ID:  X64_0x7f_8_NETIO!CompareSecurityContexts+6a

BUCKET_ID:  X64_0x7f_8_NETIO!CompareSecurityContexts+6a

Followup: MachineOwner
---------