BSOD during receive on socket

NTDEV
1

Im able to send data on a kernelwinsock. But when i receive on this socket, i see a BSOD.
Here is the stack trace. Im following the sample code for wsk in the ddk src. Any kind of directions would be helpful.

IRQL_NOT_LESS_OR_EQUAL (a)
An attempt was made to access a pageable (or completely invalid) address at an
interrupt request level (IRQL) that is too high. This is usually
caused by drivers using improper addresses.
If a kernel debugger is available get the stack backtrace.
Arguments:
Arg1: 0000000000000088, memory referenced
Arg2: 0000000000000002, IRQL
Arg3: 0000000000000001, value 0 = read operation, 1 = write operation
Arg4: fffff8000266b812, address which referenced memory

MODULE_NAME: NETIO

FAULTING_MODULE: fffff8000261a000 nt

DEBUG_FLR_IMAGE_TIMESTAMP: 4a5bc18a

WRITE_ADDRESS: unable to get nt!MmSpecialPoolStart
unable to get nt!MmSpecialPoolEnd
unable to get nt!MmPoolCodeStart
unable to get nt!MmPoolCodeEnd
0000000000000088

CURRENT_IRQL: 2

FAULTING_IP:
nt!KeInsertQueueApc+42
fffff800`0266b812 f0480fbaab8800000000 lock bts qword ptr [rbx+0x88],0x0

DEFAULT_BUCKET_ID: VISTA_BETA2

BUGCHECK_STR: 0xA

LAST_CONTROL_TRANSFER: from fffff800027816d2 to fffff80002683f60

STACK_TEXT:
fffff88001e1af78 fffff800027816d2 : 0000000000000088 fffffa8007c95260 0000000000000065 fffff800026ca314 : nt!DbgBreakPointWithStatus
fffff88001e1af80 fffff800027824be : 0000000000000003 0000000000000000 fffff800026c6ee0 000000000000000a : nt!HeadlessDispatch+0x192
fffff88001e1afe0 fffff8000268c004 : 0000000000000000 00000000000007ff fffffa80069ed040 fffff800027096a2 : nt!KeEnterKernelDebugger+0x76e
fffff88001e1b6b0 fffff8000268b469 : 000000000000000a 0000000000000088 0000000000000002 0000000000000001 : nt!KeBugCheckEx+0x104
fffff88001e1b6f0 fffff8000268a0e0 : fffffa8006fdd2b8 0000000000000000 fffffa8006fdd1a0 000000000000000d : nt!KeSynchronizeExecution+0x3d59
fffff88001e1b830 fffff8000266b812 : 0000000000026200 fffff80002bfc472 fffffa8007ea1c68 fffff80002bfeae7 : nt!KeSynchronizeExecution+0x29d0
fffff88001e1b9c0 fffff8000268ed4b : 0000000000000000 00000000a000000c 0000000000000000 fffff8000266b872 : nt!KeInsertQueueApc+0x42
fffff88001e1ba20 fffff88002c844d2 : 0000000000000000 fffffa8006ca3202 0000000000000000 0000000000000000 : nt!memset+0xccb
fffff88001e1bb00 fffff8800187898e : fffffa8007d9bf70 0000000000000000 fffffa8007d9bf70 0000000000000000 : afd+0x14d2
fffff88001e1bb60 fffff88000f92173 : fffffa8007d4a1a0 fffffa800788e010 0000000000000001 0000000000000001 : tcpip+0x7898e
fffff88001e1bbc0 fffff88001872837 : fffffa8007d9bd30 0000000000000001 fffffa8006fe41a0 fffffa800756d860 : NETIO!NetioDereferenceNetBufferListChain+0xf3
fffff88001e1bc40 fffff88000efe46f : fffffa8006fe41a0 0000000000000000 fffffa8006fe41a0 fffff88002f90660 : tcpip+0x72837
fffff88001e1bc70 fffff88000efe5ad : fffffa8000000000 fffffa8007d9bd30 0000000000000001 0000000000000000 : NDIS!NdisOidRequest+0x11f
fffff88001e1bd10 fffff88002f4e5c9 : fffffa8007565000 fffff88002f90660 0000000000000001 0000000000000002 : NDIS!NdisMSendNetBufferListsComplete+0x6d
fffff88001e1bd50 fffff88002f69433 : fffffa800758b8c0 fffff88002f90660 0000000000000001 0000000000000002 : nvm62x64+0x55c9
fffff88001e1bd80 fffff88002f68c6d : fffff88002f90660 fffff88002f90660 0000000000000000 0000000000000001 : nvm62x64!PARAM_InitClient+0x1274b
fffff88001e1bdc0 fffff88002f6608d : fffffa8000000000 fffffa8007565000 0000000000000000 fffff80002745450 : nvm62x64!PARAM_InitClient+0x11f85
fffff88001e1be10 fffff88002f50713 : 0000000000000000 0000000000000000 fffff880009bf180 fffff80002771bcf : nvm62x64!PARAM_InitClient+0xf3a5
fffff88001e1be40 fffff88000e5c653 : 000000000001e8e9 fffffa8000000026 0000000000000000 0000000000000180 : nvm62x64+0x7713
fffff88001e1be70 fffff800026975dc : fffffa80077e5cc8 fffff88000000000 0000000000000000 fffff880009bf180 : NDIS!NdisIfAllocateNetLuidIndex+0x8803
fffff88001e1bf00 fffff80002692065 : 6c894802b2f7418d fffffa8007c95260 0000000000000000 fffff88000e41c50 : nt!KeRemoveQueueEx+0xe1c
fffff88001e1bfb0 fffff80002691e7c : fffffa80077e5ca0 0000000000000000 0000000000000000 fffff88000000001 : nt!SeAccessCheckWithHint+0xdd5
fffff88004067460 fffff800026d7793 : fffff80002687d36 fffff80002687da2 fffffa80026f7330 fffff88004067501 : nt!SeAccessCheckWithHint+0xbec
fffff88004067490 fffff80002687da2 : fffffa80026f7330 fffff88004067501 fffffa8000000000 0000000000000001 : nt!ExDisableResourceBoostLite+0x2c3
fffff880040674a0 fffff800027272bc : fffffa80026fbbc0 fffff880040676fc 0000000008000000 0000000000000001 : nt!KeSynchronizeExecution+0x692
fffff88004067630 fffff8000272dd1e : fffffa8007d1e110 fffffa80026f7360 0000000000000000 fffffa8007c83d50 : nt!MmIsNonPagedSystemAddressValid+0x40c
fffff88004067660 fffff80002762a78 : fffffa80026f7330 00000000000cfd11 00000000000cfd12 0000000000080000 : nt!PsGetCurrentThreadPreviousMode+0xc8e
fffff88004067690 fffff8000279cc15 : 0000000000000000 00000000000fffff 0000000000100000 0000000000000001 : nt!KeAttachProcess+0x4548
fffff880040677b0 fffff8000279dbb3 : 0000000000000000 0000000000000000 0000000000000058 fffff880012fc3aa : nt!FsRtlOplockBreakToNone+0xc95
fffff88004067840 fffff880012f7e66 : 0000000000000000 fffff880012fc7e1 0000000000000000 fffffa80079dd1b0 : nt!MmAllocateContiguousMemorySpecifyCache+0x53
fffff88004067880 fffff88001309f7f : 000000000000000c fffff800027be4d3 fffffa8007c83cf0 fffff88004067a30 : storport!DllInitialize+0x716
fffff880040678c0 fffff8800130a134 : fffffa80079dd1b0 fffff880012f39d1 0000000000000000 fffffa8000000000 : storport!StorPortExtendedFunction+0x20ef
fffff88004067940 fffff88001344db9 : 0000000020206f49 0000000000000001 0000000000000001 0000000020206f49 : storport!StorPortExtendedFunction+0x22a4
fffff88004067980 fffff880013441d0 : fffff88001310110 fffffa8007056060 000000000000002c fffffa8007c83d50 : storport!StorPortInitialize+0x38cd9
fffff880040679d0 fffff800029a43a7 : fffffa8007c83d50 fffff88004067ca0 fffffa8007c83d50 fffffa80079dd1b0 : storport!StorPortInitialize+0x380f0
fffff88004067a10 fffff800029a4c06 : 0000000000000000 0000000000000000 0000000000000000 0000000000000000 : nt!NtMapViewOfSection+0x17a7
fffff88004067b40 fffff8000268b153 : fffffa8007c95b30 0000000000000001 fffffa8007c95260 fffff8000299f094 : nt!NtDeviceIoControlFile+0x56
fffff88004067bb0 00000000770eff2a : 000007fefd36b399 0000000000000000 00000000013a1198 0000000000000001 : nt!KeSynchronizeExecution+0x3a43
000000000016f938 0000000000000000 : 0000000000000000 0000000000000000 0000000000000000 0000000000000000 : ntdll!NtDeviceIoControlFile+0xa

STACK_COMMAND: kb

FOLLOWUP_IP:
NETIO!NetioDereferenceNetBufferListChain+f3
fffff880`00f92173 4c8b742440 mov r14,[rsp+0x40]

FAULTING_SOURCE_CODE:

SYMBOL_STACK_INDEX: a

FOLLOWUP_NAME: MachineOwner

SYMBOL_NAME: NETIO!NetioDereferenceNetBufferListChain+f3

IMAGE_NAME: NETIO.SYS

2

Arg1: 0000000000000088, memory referenced

Well, it seems like you are trying to access some null pointer. Do you check for NULLs before accessing data inside pointer?

3

I do have checks gaurding this. Also, im not on the stack. my driver is vmpwsk.sys. Its a virtual storport miniport trying to do socket operations. Also, this bsod is seen intermittently.

4

I am developing the file system like fastfat.

When I saved the powerpoint file in my filesystem at test, the powerpoint
document sometimes changed the read-only mode with message “file xxx is
currently using…”.

I traced that IoCheckShareAccess in IRP_MJ_CREATE processing return the
STATUS_SHARING_VIOLATION with conflict of share mode.

At my fsd,

  1. IRP_MJ_CREATE: lock the file by IoCheckShareAccess(,FALSE) &
    IoUpdateShareAccess()

  2. IRP_MJ_CLEANUP : unlock the file by IoRemoveShareAccess()

At the normal case, the many steps has occurred by turns, 12121212…

But, At the error case, shuffled 1212112122… with error.

  1. Why?

  2. Must I synchronize the IRP_MJ_CREATE and IRP_MJ_CLEANUP? What kind of
    method?

Please help me,

5

You should ask this on NTFSD which is the file system forum. Also you
should fix the subject to reflect what you are asking.

Don Burn (MVP, Windows DKD)
Windows Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr

“=?ks_c_5601-1987?B?s9fAzMauv8I=?=” wrote in
message news:xxxxx@ntdev:

> I am developing the file system like fastfat.
>
> When I saved the powerpoint file in my filesystem at test, the powerpoint
> document sometimes changed the read-only mode with message “file xxx is
> currently using…”.
>
> I traced that IoCheckShareAccess in IRP_MJ_CREATE processing return the
> STATUS_SHARING_VIOLATION with conflict of share mode.
>
>
>
> At my fsd,
>
> 1) IRP_MJ_CREATE: lock the file by IoCheckShareAccess(,FALSE) &
> IoUpdateShareAccess()
>
> 2) IRP_MJ_CLEANUP : unlock the file by IoRemoveShareAccess()
>
>
>
> At the normal case, the many steps has occurred by turns, 12121212…
>
> But, At the error case, shuffled 1212112122… with error.
>
>
>
> 1) Why?
>
> 2) Must I synchronize the IRP_MJ_CREATE and IRP_MJ_CLEANUP? What kind of
> method?
>
>
> Please help me,