made a custom queue data structure...need help

I believe something in this code is corrupting the stack…not sure… :frowning: but my pool is all messed up…windbg is no help in finding the problem

typedef struct ___cqueueitem {
void *Data;
struct ___cqueueitem *Next;
} CQUEUEITEM, *PCQUEUEITEM;

typedef struct ___CQueue {
unsigned int Size;
KSPIN_LOCK SpinLock;
PCQUEUEITEM First;
PCQUEUEITEM Last;
} CQUEUE, *PCQUEUE;

PCQUEUE CQueueCreate() {
PCQUEUE queue = (PCQUEUE)ExAllocatePoolWithTag(NonPagedPool, sizeof(CQUEUE), ‘pcq’);
if (!queue) {
return NULL;
}

RtlZeroMemory(queue, sizeof(CQUEUE));

//queue->SpinLock = (PKSPIN_LOCK)ExAllocatePoolWithTag(NonPagedPool, sizeof(KSPIN_LOCK), ‘ksl’);
queue->Size = 0;
KeInitializeSpinLock(&queue->SpinLock);

return queue;
}

void CQueuePush(PCQUEUE queue, void *data) {
KLOCK_QUEUE_HANDLE lockHandle;

PCQUEUEITEM qItem = (PCQUEUEITEM)ExAllocatePoolWithTag(NonPagedPool, sizeof(CQUEUEITEM), ‘cqi’);
if (!qItem) {
return;
}
RtlZeroMemory(qItem, sizeof(CQUEUEITEM));
qItem->Data = data;

KeAcquireInStackQueuedSpinLock(&queue->SpinLock, &lockHandle);

if (!queue->First) {
queue->First = qItem;
queue->Last = qItem;
}

else {
queue->Last->Next = qItem;
queue->Last = qItem;
}

++(queue->Size);

KeReleaseInStackQueuedSpinLock(&lockHandle);
}

void* CQueuePop(PCQUEUE queue) {
void *qItemData = NULL;

KLOCK_QUEUE_HANDLE lockHandle;
PCQUEUEITEM poppedItem = NULL;

KeAcquireInStackQueuedSpinLock(&queue->SpinLock, &lockHandle);
if (queue && queue->Size) {
poppedItem = queue->First;
if (!poppedItem) {
KeReleaseInStackQueuedSpinLock(&lockHandle);
return NULL;
}
qItemData = poppedItem->Data;

queue->First = queue->First->Next;

–(queue->Size);
}

if (poppedItem) {
ExFreePoolWithTag(poppedItem, ‘cqi’);
}
KeReleaseInStackQueuedSpinLock(&lockHandle);

return qItemData;
}

void CQueueFlush(PCQUEUE queue) {
ExFreePoolWithTag(queue, ‘pcq’);
}

well running internet explorer instead of google chrome gives a stack that points to my driver…

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

DRIVER_CORRUPTED_EXPOOL (c5)
An attempt was made to access a pageable (or completely invalid) address at an
interrupt request level (IRQL) that is too high. This is
caused by drivers that have corrupted the system pool. Run the driver
verifier against any new (or suspect) drivers, and if that doesn’t turn up
the culprit, then use gflags to enable special pool.
Arguments:
Arg1: ffffe00000000001, memory referenced
Arg2: 0000000000000002, IRQL
Arg3: 0000000000000000, value 0 = read operation, 1 = write operation
Arg4: fffff800f70bc972, address which referenced memory

Debugging Details:

BUGCHECK_P1: ffffe00000000001

BUGCHECK_P2: 2

BUGCHECK_P3: 0

BUGCHECK_P4: fffff800f70bc972

BUGCHECK_STR: 0xC5_2

CURRENT_IRQL: 2

FAULTING_IP:
nt!ExDeferredFreePool+102
fffff800`f70bc972 488b10 mov rdx,qword ptr [rax]

CPU_COUNT: 1

CPU_MHZ: 6a0

CPU_VENDOR: GenuineIntel

CPU_FAMILY: 6

CPU_MODEL: 45

CPU_STEPPING: 1

DEFAULT_BUCKET_ID: WIN8_DRIVER_FAULT

PROCESS_NAME: System

ANALYSIS_VERSION: 10.0.10240.9 amd64fre

TRAP_FRAME: ffffd000e60ee5d0 – (.trap 0xffffd000e60ee5d0)
NOTE: The trap frame does not contain all registers.
Some register values may be zeroed or incorrect.
rax=ffffe00000000001 rbx=0000000000000000 rcx=fffff800f7106210
rdx=ffffe00000000001 rsi=0000000000000000 rdi=0000000000000000
rip=fffff800f70bc972 rsp=ffffd000e60ee760 rbp=000000000000001e
r8=ffffe0007d2a4840 r9=0000000000000000 r10=0000000000000001
r11=0000000000000000 r12=0000000000000000 r13=0000000000000000
r14=0000000000000000 r15=0000000000000000
iopl=0 nv up ei ng nz na pe nc
nt!ExDeferredFreePool+0x102:
fffff800f70bc972 488b10 mov rdx,qword ptr [rax] ds:ffffe00000000001=???
Resetting default scope

LAST_CONTROL_TRANSFER: from fffff800f6ffb98e to fffff800f6f72e90

STACK_TEXT:
ffffd000e60edcd8 fffff800f6ffb98e : 0000000000000000 0000000000000000 ffffd000e60ede40 fffff800f6ef27a4 : nt!DbgBreakPointWithStatus
ffffd000e60edce0 fffff800f6ffb29f : 0000000000000003 ffffe00000000001 fffff800f6f7a290 00000000000000c5 : nt!KiBugCheckDebugBreak+0x12
ffffd000e60edd40 fffff800f6f6c3a4 : 0000000000000000 0000000000000000 0000000000000000 0000000000000000 : nt!KeBugCheck2+0x8ab
ffffd000e60ee450 fffff800f6f77de9 : 000000000000000a ffffe00000000001 0000000000000002 0000000000000000 : nt!KeBugCheckEx+0x104
ffffd000e60ee490 fffff800f6f7663a : 0000000000000000 0000000000000000 ffffe0007e074d00 fffff800f6f77533 : nt!KiBugCheckDispatch+0x69
ffffd000e60ee5d0 fffff800f70bc972 : 0000000000000010 0000000000000295 ffffd000e60ee788 0000000000000018 : nt!KiPageFault+0x23a
ffffd000e60ee760 fffff800f70bb84e : ffffe0007ebf9bb0 ffffe0007d278830 0000000000000000 0000000000000002 : nt!ExDeferredFreePool+0x102
ffffd000e60ee7e0 fffff8015a5ea10b : 0000000000000122 ffffe0007d0d6010 fffff8015a5ec700 0000000000000046 : nt!ExFreePoolWithTag+0x84e
ffffd000e60ee8d0 fffff80158c066cf : ffffe0007df5fa00 fffff8015a5ea098 ffffe0007d0d6010 fffff80100000043 : ProxyOneDriver!FlowDeleteFn+0x73 [d:\clients\christopher\http_filter\http_driver\driver.c @ 1517]
ffffd000e60ee900 fffff80158c060f4 : 000000000000031b ffffe000815c0014 ffffe0008100ff00 ffffd000e600ff00 : NETIO!WfpProcessFlowDelete+0x46f
ffffd000e60ee9a0 fffff801590df2a1 : 0000000000000013 ffffe0007e758b40 ffffe00080d3c4e0 ffffe0000000000a : NETIO!KfdAleNotifyFlowDeletion+0x24
ffffd000e60eea00 fffff80158c079c5 : ffffe00080d3c6c0 ffffe00080d3c6c0 fffff8015925cce0 fffff80158c07990 : tcpip!TcpCleanupTcbWorkQueueRoutine+0x1e1
ffffd000e60eeb90 fffff800f6ed237f : ffffe0007e07cdc0 ffffe00080ec5860 0000000000000000 fffff80158c4ccc0 : NETIO!NetiopIoWorkItemRoutine+0x35
ffffd000e60eebe0 fffff800f6ed2a2f : 0000000000000000 fffff800f6ed2284 ffffe00080918040 0000000000000005 : nt!IopProcessWorkItem+0xfb
ffffd000e60eec50 fffff800f6f18c10 : ffffe0007d184040 ffffe00080918040 0000000000000080 ffffe00080918040 : nt!ExpWorkerThread+0x69f
ffffd000e60eed00 fffff800f6f728c6 : fffff800f711b180 ffffe00080918040 ffffe0007d184040 ffffd000d7585d90 : nt!PspSystemThreadStartup+0x58
ffffd000e60eed60 0000000000000000 : ffffd000e60ef000 ffffd000e60e9000 0000000000000000 0000000000000000 : nt!KiStartSystemThread+0x16

STACK_COMMAND: kb

FOLLOWUP_IP:
nt!ExDeferredFreePool+102
fffff800`f70bc972 488b10 mov rdx,qword ptr [rax]

SYMBOL_STACK_INDEX: 6

SYMBOL_NAME: nt!ExDeferredFreePool+102

FOLLOWUP_NAME: Pool_corruption

IMAGE_NAME: Pool_Corruption

DEBUG_FLR_IMAGE_TIMESTAMP: 0

MODULE_NAME: Pool_Corruption

BUCKET_ID_FUNC_OFFSET: 102

FAILURE_BUCKET_ID: 0xC5_2_nt!ExDeferredFreePool

BUCKET_ID: 0xC5_2_nt!ExDeferredFreePool

PRIMARY_PROBLEM_CLASS: 0xC5_2_nt!ExDeferredFreePool

ANALYSIS_SOURCE: KM

FAILURE_ID_HASH_STRING: km:0xc5_2_nt!exdeferredfreepool

FAILURE_ID_HASH: {0e971f5b-bd0d-a80e-a2c0-cd331176cf49}

Followup: Pool_corruption

Why don’t you use the standard LIST_ENTRY and friends to manage the list? If you want a singly linked list, SLIST_ENTRY instead.

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@gmail.com
Sent: Monday, August 22, 2016 6:36 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] made a custom queue data structure…need help

well running internet explorer instead of google chrome gives a stack that points to my driver…

kd> !analyze -v


Bugcheck Analysis



DRIVER_CORRUPTED_EXPOOL (c5)
An attempt was made to access a pageable (or completely invalid) address at an interrupt request level (IRQL) that is too high. This is caused by drivers that have corrupted the system pool. Run the driver verifier against any new (or suspect) drivers, and if that doesn’t turn up the culprit, then use gflags to enable special pool.
Arguments:
Arg1: ffffe00000000001, memory referenced
Arg2: 0000000000000002, IRQL
Arg3: 0000000000000000, value 0 = read operation, 1 = write operation
Arg4: fffff800f70bc972, address which referenced memory

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

BUGCHECK_P1: ffffe00000000001

BUGCHECK_P2: 2

BUGCHECK_P3: 0

BUGCHECK_P4: fffff800f70bc972

BUGCHECK_STR: 0xC5_2

CURRENT_IRQL: 2

FAULTING_IP:
nt!ExDeferredFreePool+102
fffff800f70bc972 488b10 mov rdx,qword ptr [rax]<br><br>CPU_COUNT: 1<br><br>CPU_MHZ: 6a0<br><br>CPU_VENDOR: GenuineIntel<br><br>CPU_FAMILY: 6<br><br>CPU_MODEL: 45<br><br>CPU_STEPPING: 1<br><br>DEFAULT_BUCKET_ID: WIN8_DRIVER_FAULT<br><br>PROCESS_NAME: System<br><br>ANALYSIS_VERSION: 10.0.10240.9 amd64fre<br><br>TRAP_FRAME: ffffd000e60ee5d0 -- (.trap 0xffffd000e60ee5d0)<br>NOTE: The trap frame does not contain all registers.<br>Some register values may be zeroed or incorrect.<br>rax=ffffe00000000001 rbx=0000000000000000 rcx=fffff800f7106210<br>rdx=ffffe00000000001 rsi=0000000000000000 rdi=0000000000000000<br>rip=fffff800f70bc972 rsp=ffffd000e60ee760 rbp=000000000000001e<br> r8=ffffe0007d2a4840 r9=0000000000000000 r10=0000000000000001<br>r11=0000000000000000 r12=0000000000000000 r13=0000000000000000<br>r14=0000000000000000 r15=0000000000000000<br>iopl=0 nv up ei ng nz na pe nc<br>nt!ExDeferredFreePool+0x102:<br>fffff800f70bc972 488b10 mov rdx,qword ptr [rax] ds:ffffe00000000001=????????????????<br>Resetting default scope<br><br>LAST_CONTROL_TRANSFER: from fffff800f6ffb98e to fffff800f6f72e90<br><br>STACK_TEXT: <br>ffffd000e60edcd8 fffff800f6ffb98e : 0000000000000000 0000000000000000 ffffd000e60ede40 fffff800f6ef27a4 : nt!DbgBreakPointWithStatus<br>ffffd000e60edce0 fffff800f6ffb29f : 0000000000000003 ffffe00000000001 fffff800f6f7a290 00000000000000c5 : nt!KiBugCheckDebugBreak+0x12<br>ffffd000e60edd40 fffff800f6f6c3a4 : 0000000000000000 0000000000000000 0000000000000000 0000000000000000 : nt!KeBugCheck2+0x8ab<br>ffffd000e60ee450 fffff800f6f77de9 : 000000000000000a ffffe00000000001 0000000000000002 0000000000000000 : nt!KeBugCheckEx+0x104<br>ffffd000e60ee490 fffff800f6f7663a : 0000000000000000 0000000000000000 ffffe0007e074d00 fffff800f6f77533 : nt!KiBugCheckDispatch+0x69<br>ffffd000e60ee5d0 fffff800f70bc972 : 0000000000000010 0000000000000295 ffffd000e60ee788 0000000000000018 : nt!KiPageFault+0x23a<br>ffffd000e60ee760 fffff800f70bb84e : ffffe0007ebf9bb0 ffffe0007d278830 0000000000000000 0000000000000002 : nt!ExDeferredFreePool+0x102<br>ffffd000e60ee7e0 fffff8015a5ea10b : 0000000000000122 ffffe0007d0d6010 fffff8015a5ec700 0000000000000046 : nt!ExFreePoolWithTag+0x84e<br>ffffd000e60ee8d0 fffff80158c066cf : ffffe0007df5fa00 fffff8015a5ea098 ffffe0007d0d6010 fffff80100000043 : ProxyOneDriver!FlowDeleteFn+0x73 [d:\clients\christopher\http_filter\http_driver\driver.c @ 1517]<br>ffffd000e60ee900 fffff80158c060f4 : 000000000000031b ffffe000815c0014 ffffe0008100ff00 ffffd000e600ff00 : NETIO!WfpProcessFlowDelete+0x46f<br>ffffd000e60ee9a0 fffff801590df2a1 : 0000000000000013 ffffe0007e758b40 ffffe00080d3c4e0 ffffe0000000000a : NETIO!KfdAleNotifyFlowDeletion+0x24<br>ffffd000e60eea00 fffff80158c079c5 : ffffe00080d3c6c0 ffffe00080d3c6c0 fffff8015925cce0 fffff80158c07990 : tcpip!TcpCleanupTcbWorkQueueRoutine+0x1e1<br>ffffd000e60eeb90 fffff800f6ed237f : ffffe0007e07cdc0 ffffe00080ec5860 0000000000000000 fffff80158c4ccc0 : NETIO!NetiopIoWorkItemRoutine+0x35<br>ffffd000e60eebe0 fffff800f6ed2a2f : 0000000000000000 fffff800f6ed2284 ffffe00080918040 0000000000000005 : nt!IopProcessWorkItem+0xfb<br>ffffd000e60eec50 fffff800f6f18c10 : ffffe0007d184040 ffffe00080918040 0000000000000080 ffffe00080918040 : nt!ExpWorkerThread+0x69f<br>ffffd000e60eed00 fffff800f6f728c6 : fffff800f711b180 ffffe00080918040 ffffe0007d184040 ffffd000d7585d90 : nt!PspSystemThreadStartup+0x58<br>ffffd000e60eed60 0000000000000000 : ffffd000e60ef000 ffffd000e60e9000 0000000000000000 0000000000000000 : nt!KiStartSystemThread+0x16<br><br>STACK_COMMAND: kb<br><br>FOLLOWUP_IP: <br>nt!ExDeferredFreePool+102<br>fffff800f70bc972 488b10 mov rdx,qword ptr [rax]

SYMBOL_STACK_INDEX: 6

SYMBOL_NAME: nt!ExDeferredFreePool+102

FOLLOWUP_NAME: Pool_corruption

IMAGE_NAME: Pool_Corruption

DEBUG_FLR_IMAGE_TIMESTAMP: 0

MODULE_NAME: Pool_Corruption

BUCKET_ID_FUNC_OFFSET: 102

FAILURE_BUCKET_ID: 0xC5_2_nt!ExDeferredFreePool

BUCKET_ID: 0xC5_2_nt!ExDeferredFreePool

PRIMARY_PROBLEM_CLASS: 0xC5_2_nt!ExDeferredFreePool

ANALYSIS_SOURCE: KM

FAILURE_ID_HASH_STRING: km:0xc5_2_nt!exdeferredfreepool

FAILURE_ID_HASH: {0e971f5b-bd0d-a80e-a2c0-cd331176cf49}

Followup: Pool_corruption
---------


NTDEV is sponsored by OSR

Visit the list online at: http:

MONTHLY seminars on crash dump analysis, WDF, Windows internals and software drivers!
Details at http:

To unsubscribe, visit the List Server section of OSR Online at http:</http:></http:></http:>

because I need a queue which is first in first out…not first in last out…

one question…could it corrupt the stack in a C driver if i don’t declare all of my variables at the top of functions?

Are you protecting the list? In what context are you accessing the list;
IRP_MJ_READ/WRITE?

On Mon, Aug 22, 2016 at 9:48 PM wrote:

> because I need a queue which is first in first out…not first in last
> out…
>
>
> one question…could it corrupt the stack in a C driver if i don’t declare
> all of my variables at the top of functions?
>
>
> —
> NTDEV is sponsored by OSR
>
> Visit the list online at: <
> http://www.osronline.com/showlists.cfm?list=ntdev&gt;
>
> MONTHLY seminars on crash dump analysis, WDF, Windows internals and
> software drivers!
> Details at http:
>
> To unsubscribe, visit the List Server section of OSR Online at <
> http://www.osronline.com/page.cfm?name=ListServer&gt;
></http:>

i actually don’t believe it’s the list…i believe exallocating and freeing nonpaged memory too many times, is corrupting the pool…i have just found ExInitializeNPagedLookasideList .i will give this a try

On Aug 22, 2016, at 6:48 PM, xxxxx@gmail.com wrote:

because I need a queue which is first in first out…not first in last out…

Are you not aware that the LIST_ENTRY APIs can insert and remove at either end of the list? As long as you insert at the end on remove from the beginning, you’ll get FIFO.

Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

Your pool tag definitions should use four characters. Those characters should be greater than 0x20 (space) and lesser than 0x126 (tilde).

Now the tag is a ULONG or DWORD (4 bytes) so when you specify a three bytes tag, the compiler “completes” the constant with a zero which is not allowed (look at the disassembly).


Tag [in]

The pool tag to use for the allocated memory. Specify the pool tag as a character literal of up to four characters delimited by single quotation marks (for example, ‘Tag1’). The string is usually specified in reverse order (for example, ‘1gaT’). Each ASCII character in the tag must be a value in the range 0x20 (space) to 0x126 (tilde). Each allocation code path should use a unique pool tag to help debuggers and verifiers identify the code path.

use the following definition:

#define MYTAG (ULONG)’ gaT’ // Note the “ending” space.

So now you understand why you should use a preprocessor macro to “alias” the pool tag. You have to edit every call to ExAllocatePoolWithTag instead of just editing a single preprocessor definition macro.

This may not fix the problem but you should follow these simple rules. Bug tracking consumes a lot of time.

On Aug 22, 2016, at 6:36 PM, xxxxx@gmail.com wrote:

well running internet explorer instead of google chrome gives a stack that points to my driver…

I didn’t see anything unusual in the code you posted. It doesn’t look like a stack overflow, it looks like a heap overflow. You’re storing allocated data here. Have you desk-checked the program to make sure you’re not running off the end (or beginning) of one of your allocations?

Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

> because I need a queue which is first in first out…not first in last out…

A combination of

InsertHeadList()
RemoveTailList()

OR

InsertTailList()
RemoveHeadList()

gives a FIFO queue.

BTW I think a crash is related to a memory corruption by a queue user, not the queue code itself. I would suggest to activate Driver Verifier for the driver ( choose Special Pool settings ).

you can release memory after the lock was released, this will reduce time threads spend trying to acquire the lock.

the people who designed windows really did ah very bad job…blue screens should not happen this much…

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

DRIVER_VERIFIER_DETECTED_VIOLATION (c4)
A device driver attempting to corrupt the system has been caught. This is
because the driver was specified in the registry as being suspect (by the
administrator) and the kernel has enabled substantial checking of this driver.
If the driver attempts to corrupt the system, bugchecks 0xC4, 0xC1 and 0xA will
be among the most commonly seen crashes.
Arguments:
Arg1: 0000000000005002, subclass of driver violation.
Arg2: 0000000000010000
Arg3: 0000000000000001
Arg4: 0000000000000004

Debugging Details:

“KERNELBASE.dll” was not found in the image list.
Debugger will attempt to load “KERNELBASE.dll” at given base 00000000`00000000.

Please provide the full image name, including the extension (i.e. kernel32.dll)
for more reliable results.Base address and size overrides can be given as
.reload <image.ext>=,.
Unable to add module at 0000000000000000<br><br>BUGCHECK_P1: 5002<br><br>BUGCHECK_P2: 10000<br><br>BUGCHECK_P3: 1<br><br>BUGCHECK_P4: 4<br><br>BUGCHECK_STR: 0xc4_5002<br><br>CPU_COUNT: 1<br><br>CPU_MHZ: 6a0<br><br>CPU_VENDOR: GenuineIntel<br><br>CPU_FAMILY: 6<br><br>CPU_MODEL: 45<br><br>CPU_STEPPING: 1<br><br>DEFAULT_BUCKET_ID: WIN8_DRIVER_FAULT<br><br>PROCESS_NAME: chrome.exe<br><br>CURRENT_IRQL: 2<br><br>ANALYSIS_VERSION: 10.0.10240.9 amd64fre<br><br>LAST_CONTROL_TRANSFER: from fffff80074a6898e to fffff800749dfe90<br><br>STACK_TEXT: <br>ffffd0010cdf9958 fffff80074a6898e : 0000000000000000 0000000000000000 ffffd0010cdf9ac0 fffff8007495f7a4 : nt!DbgBreakPointWithStatus<br>ffffd0010cdf9960 fffff80074a6829f : 0000000000000003 0000000000005002 fffff800749e7290 00000000000000c4 : nt!KiBugCheckDebugBreak+0x12<br>ffffd0010cdf99c0 fffff800749d93a4 : ffffd0010cdfa6a8 fffff80074efe130 ffffcf81cfa4e790 0000000000000002 : nt!KeBugCheck2+0x8ab<br>ffffd0010cdfa0d0 fffff800ec564d15 : 00000000000000c4 0000000000005002 0000000000010000 0000000000000001 : nt!KeBugCheckEx+0x104<br>ffffd0010cdfa110 fffff800ec54532f : ffffcf8100000001 ffffd00100000000 fffff800edc9a700 0000000000000000 : NETIO!StreamVerifierBreak+0x29<br>ffffd0010cdfa150 fffff800ec524f2b : ffffd0010cdfa338 0000000000000000 ffffd0010cdfa300 ffffe00036f47cb0 : NETIO!StreamNormalizeClassifyOut+0x20897<br>ffffd0010cdfa1b0 fffff800ec52480f : 0000000000080000 ffffe00036f47be0 ffffd0010cdfa371 0000000000000000 : NETIO!StreamInvokeCalloutAndNormalizeAction+0x22b<br>ffffd0010cdfa280 fffff800ec52e9a2 : ffffe00037b00014 fffff800edc975b0 ffffd00100000002 ffffd0010cdfadd8 : NETIO!StreamProcessCallout+0x76f<br>ffffd0010cdfa3c0 fffff800ec515549 : 0000000000000014 ffffd0010cdfadd8 ffffe00039696ad0 ffffd0010cdfac90 : NETIO!ProcessCallout+0x972<br>ffffd0010cdfa530 fffff800ec514250 : 0000000000000000 ffffd0010cdfa830 ffffd0010cdfad00 fffff800749228cd : NETIO!ArbitrateAndEnforce+0x2c9<br>ffffd0010cdfa730 fffff800ec5235a0 : 405fd6a7ef9db22d 0000000000000000 0000000000000000 0000000000000000 : NETIO!KfdClassify+0x831<br>ffffd0010cdfabf0 fffff800ec523acd : 0000000000000000 ffffd0010cdfb208 00001f800010000f 0053002b002b0010 : NETIO!StreamClassify+0x220<br>ffffd0010cdfad80 fffff800ec525c5d : 0000000000000000 ffffd0010cdfb4e0 fffffa8000130000 ffffe00037db6d10 : NETIO!StreamCommonInspect+0x25d<br>ffffd0010cdfb120 fffff800eca5ff66 : ffffe00037db6d10 ffffd0010cdfb290 ffffe00036f39790 ffffe00036e4f960 : NETIO!WfpStreamInspectDisconnect+0x23d<br>ffffd0010cdfb190 fffff800eca5e6a7 : fffff800ed2c85bc 00000000c0000016 ffffd0010cdfb500 ffffd0010cdfb450 : tcpip!TcpDisconnectTcb+0xf6<br>ffffd0010cdfb300 fffff80074932fc3 : 0000000000000000 fffff800748f69a7 ffffffffffffffff ffffd0010cdfb3c0 : tcpip!TcpTlConnectionDisconnectCalloutRoutine+0x28<br>ffffd0010cdfb330 fffff800eca5f927 : fffff800eca5e680 ffffd0010cdfb450 0000000000000100 fffff800748fa419 : nt!KeExpandKernelStackAndCalloutInternal+0xf3<br>ffffd0010cdfb420 fffff800ed2e335c : 0000000000000000 ffffd0010cdfb4e9 0000000000000000 fffff6fc00769640 : tcpip!TcpTlConnectionDisconnect+0x5f<br>ffffd0010cdfb490 fffff800ed2e3bc6 : 0000000000000000 ffffe00036f208a0 ffffe00036f66930 0000000000000000 : afd!AfdBeginDisconnect+0x10c<br>ffffd0010cdfb550 fffff800ed2c718b : ffffe00037ab8080 ffffe00036f0acb0 00000000058ef238 ffffd0010cdfb840 : afd!AfdPartialDisconnect+0x226<br>ffffd0010cdfb690 fffff80074d280f2 : 0000000000000010 ffffe00036f0acb0 ffffd0010cdfbb50 0000000000000001 : afd!AfdFastIoDeviceControl+0x17b<br>ffffd0010cdfb9e0 fffff80074cf9572 : ffffcf81cfa38e50 0000000000000698 0000000000000001 0000000000000000 : nt!IopXxxControlFile+0x7c2<br>ffffd0010cdfbb20 fffff800749e4ab3 : ffffe00037ab8080 00000000057eea28 ffffd0010cdfbba8 00000000058ef81c : nt!NtDeviceIoControlFile+0x56<br>ffffd0010cdfbb90 00000000778f2352 : 00000000778f1f51 000000237793c2cc 0000000000000023 0000000000090042 : nt!KiSystemServiceCopyEnd+0x13<br>00000000057eea08 00000000778f1f51 : 000000237793c2cc 0000000000000023 0000000000090042 0000000000000401 : wow64cpu!CpupSyscallStub+0x2<br>00000000057eea10 000000007784219a : 0000000000000000 00000000778f1574 0000000000000000 0000000077842380 : wow64cpu!DeviceIoctlFileFault+0x31<br>00000000057eeac0 00000000778420d2 : 0000000000000000 0000000000000000 00000000057efd30 00000000057ef110 : wow64!RunCpuSimulation+0xa<br>00000000057eeb10 00007ff9fb418dab : 0000000000000000 0000000077841f60 0000000000000000 0000000000000000 : wow64!Wow64LdrpInitialize+0x172<br>00000000057ef050 00007ff9fb418c8e : 00000000057ef110 0000000000000000 00000000ffd8f000 0000000000000000 : ntdll!_LdrpInitialize+0xcb<br>00000000057ef0c0 0000000000000000 : 0000000000000000 0000000000000000 0000000000000000 0000000000000000 : ntdll!LdrInitializeThunk+0xe<br><br>STACK_COMMAND: kb<br><br>FOLLOWUP_IP: <br>NETIO!StreamVerifierBreak+29<br>fffff800ec564d15 cc int 3

SYMBOL_STACK_INDEX: 4

SYMBOL_NAME: NETIO!StreamVerifierBreak+29

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: NETIO

IMAGE_NAME: NETIO.SYS

DEBUG_FLR_IMAGE_TIMESTAMP: 5681bedf

BUCKET_ID_FUNC_OFFSET: 29

FAILURE_BUCKET_ID: 0xc4_5002_VRF_NETIO!StreamVerifierBreak

BUCKET_ID: 0xc4_5002_VRF_NETIO!StreamVerifierBreak

PRIMARY_PROBLEM_CLASS: 0xc4_5002_VRF_NETIO!StreamVerifierBreak

ANALYSIS_SOURCE: KM

FAILURE_ID_HASH_STRING: km:0xc4_5002_vrf_netio!streamverifierbreak

FAILURE_ID_HASH: {fcf5ef21-64f0-ce01-d68b-d6a560b84adb}

Followup: MachineOwner
---------</image.ext>

4.001278 ffffe000370ec040 ffff93d0 READY nt!KiSwapContext+0x76
nt!KiProcessDeferredReadyList+0x13b
nt!KiAbThreadUnboostCpuPriority+0x59
nt!KeAbPostRelease+0x1de
nt!MiTrimAllSystemPagableMemory+0x2d2
nt!MmVerifierTrimMemory+0xa1
nt!ViKeRaiseIrqlSanityChecks+0xd9
nt!VerifierKfRaiseIrql+0x44
ndis!NdisAcquireRWLockRead+0x30
NETIO!WfpAcquireFastReadLock+0x1b
NETIO!WfpFindAndDeRefFlowContext+0x62
NETIO!FwppStreamInject+0x160
fwpkclnt!FwpsStreamInjectAsync0+0xfa
ProxyOneDriver!InjectClonedPacket+0x85
ProxyOneDriver!HandleInjectionPacket+0x4b
ProxyOneDriver!ThreadHandleHTTPInjections+0x7d
nt!PspSystemThreadStartup+0x58
nt!KiStartSystemThread+0x16

i believe I fixed it…well, it has did over 2000 sucessful reinjections so far…my problem was i wasn’t using FwpsReferenceNetBufferList before reinjecting…sometimes it worked, and then suddenly a blue screen…looking good now

Here’s some brilliant insight that can only come from years of experience:
if Windows doesn’t crash without your driver but does crash with your driver
it is more often your driver that sucks and not the other way around.

-scott
OSR
@OSRDrivers

wrote in message news:xxxxx@ntdev…

the people who designed windows really did ah very bad job…blue screens
should not happen this much…

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

DRIVER_VERIFIER_DETECTED_VIOLATION (c4)
A device driver attempting to corrupt the system has been caught. This is
because the driver was specified in the registry as being suspect (by the
administrator) and the kernel has enabled substantial checking of this
driver.
If the driver attempts to corrupt the system, bugchecks 0xC4, 0xC1 and 0xA
will
be among the most commonly seen crashes.
Arguments:
Arg1: 0000000000005002, subclass of driver violation.
Arg2: 0000000000010000
Arg3: 0000000000000001
Arg4: 0000000000000004

Debugging Details:

“KERNELBASE.dll” was not found in the image list.
Debugger will attempt to load “KERNELBASE.dll” at given base
00000000`00000000.

Please provide the full image name, including the extension (i.e.
kernel32.dll)
for more reliable results.Base address and size overrides can be given as
.reload <image.ext>=,.
Unable to add module at 0000000000000000<br><br>BUGCHECK_P1: 5002<br><br>BUGCHECK_P2: 10000<br><br>BUGCHECK_P3: 1<br><br>BUGCHECK_P4: 4<br><br>BUGCHECK_STR: 0xc4_5002<br><br>CPU_COUNT: 1<br><br>CPU_MHZ: 6a0<br><br>CPU_VENDOR: GenuineIntel<br><br>CPU_FAMILY: 6<br><br>CPU_MODEL: 45<br><br>CPU_STEPPING: 1<br><br>DEFAULT_BUCKET_ID: WIN8_DRIVER_FAULT<br><br>PROCESS_NAME: chrome.exe<br><br>CURRENT_IRQL: 2<br><br>ANALYSIS_VERSION: 10.0.10240.9 amd64fre<br><br>LAST_CONTROL_TRANSFER: from fffff80074a6898e to fffff800749dfe90<br><br>STACK_TEXT:<br>ffffd0010cdf9958 fffff80074a6898e : 0000000000000000 0000000000000000 <br>ffffd0010cdf9ac0 fffff8007495f7a4 : nt!DbgBreakPointWithStatus<br>ffffd0010cdf9960 fffff80074a6829f : 0000000000000003 0000000000005002 <br>fffff800749e7290 00000000000000c4 : nt!KiBugCheckDebugBreak+0x12<br>ffffd0010cdf99c0 fffff800749d93a4 : ffffd0010cdfa6a8 fffff80074efe130 <br>ffffcf81cfa4e790 0000000000000002 : nt!KeBugCheck2+0x8ab<br>ffffd0010cdfa0d0 fffff800ec564d15 : 00000000000000c4 0000000000005002 <br>0000000000010000 0000000000000001 : nt!KeBugCheckEx+0x104<br>ffffd0010cdfa110 fffff800ec54532f : ffffcf8100000001 ffffd00100000000 <br>fffff800edc9a700 0000000000000000 : NETIO!StreamVerifierBreak+0x29<br>ffffd0010cdfa150 fffff800ec524f2b : ffffd0010cdfa338 0000000000000000 <br>ffffd0010cdfa300 ffffe00036f47cb0 : <br>NETIO!StreamNormalizeClassifyOut+0x20897<br>ffffd0010cdfa1b0 fffff800ec52480f : 0000000000080000 ffffe00036f47be0 <br>ffffd0010cdfa371 0000000000000000 : <br>NETIO!StreamInvokeCalloutAndNormalizeAction+0x22b<br>ffffd0010cdfa280 fffff800ec52e9a2 : ffffe00037b00014 fffff800edc975b0 <br>ffffd00100000002 ffffd0010cdfadd8 : NETIO!StreamProcessCallout+0x76f<br>ffffd0010cdfa3c0 fffff800ec515549 : 0000000000000014 ffffd0010cdfadd8 <br>ffffe00039696ad0 ffffd0010cdfac90 : NETIO!ProcessCallout+0x972<br>ffffd0010cdfa530 fffff800ec514250 : 0000000000000000 ffffd0010cdfa830 <br>ffffd0010cdfad00 fffff800749228cd : NETIO!ArbitrateAndEnforce+0x2c9<br>ffffd0010cdfa730 fffff800ec5235a0 : 405fd6a7ef9db22d 0000000000000000 <br>0000000000000000 0000000000000000 : NETIO!KfdClassify+0x831<br>ffffd0010cdfabf0 fffff800ec523acd : 0000000000000000 ffffd0010cdfb208 <br>00001f800010000f 0053002b002b0010 : NETIO!StreamClassify+0x220<br>ffffd0010cdfad80 fffff800ec525c5d : 0000000000000000 ffffd0010cdfb4e0 <br>fffffa8000130000 ffffe00037db6d10 : NETIO!StreamCommonInspect+0x25d<br>ffffd0010cdfb120 fffff800eca5ff66 : ffffe00037db6d10 ffffd0010cdfb290 <br>ffffe00036f39790 ffffe00036e4f960 : NETIO!WfpStreamInspectDisconnect+0x23d<br>ffffd0010cdfb190 fffff800eca5e6a7 : fffff800ed2c85bc 00000000c0000016 <br>ffffd0010cdfb500 ffffd0010cdfb450 : tcpip!TcpDisconnectTcb+0xf6<br>ffffd0010cdfb300 fffff80074932fc3 : 0000000000000000 fffff800748f69a7 <br>ffffffffffffffff ffffd0010cdfb3c0 : <br>tcpip!TcpTlConnectionDisconnectCalloutRoutine+0x28<br>ffffd0010cdfb330 fffff800eca5f927 : fffff800eca5e680 ffffd0010cdfb450 <br>0000000000000100 fffff800748fa419 : <br>nt!KeExpandKernelStackAndCalloutInternal+0xf3<br>ffffd0010cdfb420 fffff800ed2e335c : 0000000000000000 ffffd0010cdfb4e9 <br>0000000000000000 fffff6fc00769640 : tcpip!TcpTlConnectionDisconnect+0x5f<br>ffffd0010cdfb490 fffff800ed2e3bc6 : 0000000000000000 ffffe00036f208a0 <br>ffffe00036f66930 0000000000000000 : afd!AfdBeginDisconnect+0x10c<br>ffffd0010cdfb550 fffff800ed2c718b : ffffe00037ab8080 ffffe00036f0acb0 <br>00000000058ef238 ffffd0010cdfb840 : afd!AfdPartialDisconnect+0x226<br>ffffd0010cdfb690 fffff80074d280f2 : 0000000000000010 ffffe00036f0acb0 <br>ffffd0010cdfbb50 0000000000000001 : afd!AfdFastIoDeviceControl+0x17b<br>ffffd0010cdfb9e0 fffff80074cf9572 : ffffcf81cfa38e50 0000000000000698 <br>0000000000000001 0000000000000000 : nt!IopXxxControlFile+0x7c2<br>ffffd0010cdfbb20 fffff800749e4ab3 : ffffe00037ab8080 00000000057eea28 <br>ffffd0010cdfbba8 00000000058ef81c : nt!NtDeviceIoControlFile+0x56<br>ffffd0010cdfbb90 00000000778f2352 : 00000000778f1f51 000000237793c2cc <br>0000000000000023 0000000000090042 : nt!KiSystemServiceCopyEnd+0x13<br>00000000057eea08 00000000778f1f51 : 000000237793c2cc 0000000000000023 <br>0000000000090042 0000000000000401 : wow64cpu!CpupSyscallStub+0x2<br>00000000057eea10 000000007784219a : 0000000000000000 00000000778f1574 <br>0000000000000000 0000000077842380 : wow64cpu!DeviceIoctlFileFault+0x31<br>00000000057eeac0 00000000778420d2 : 0000000000000000 0000000000000000 <br>00000000057efd30 00000000057ef110 : wow64!RunCpuSimulation+0xa<br>00000000057eeb10 00007ff9fb418dab : 0000000000000000 0000000077841f60 <br>0000000000000000 0000000000000000 : wow64!Wow64LdrpInitialize+0x172<br>00000000057ef050 00007ff9fb418c8e : 00000000057ef110 0000000000000000 <br>00000000ffd8f000 0000000000000000 : ntdll!_LdrpInitialize+0xcb<br>00000000057ef0c0 0000000000000000 : 0000000000000000 0000000000000000 <br>0000000000000000 0000000000000000 : ntdll!LdrInitializeThunk+0xe<br><br>STACK_COMMAND: kb<br><br>FOLLOWUP_IP:<br>NETIO!StreamVerifierBreak+29<br>fffff800ec564d15 cc int 3

SYMBOL_STACK_INDEX: 4

SYMBOL_NAME: NETIO!StreamVerifierBreak+29

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: NETIO

IMAGE_NAME: NETIO.SYS

DEBUG_FLR_IMAGE_TIMESTAMP: 5681bedf

BUCKET_ID_FUNC_OFFSET: 29

FAILURE_BUCKET_ID: 0xc4_5002_VRF_NETIO!StreamVerifierBreak

BUCKET_ID: 0xc4_5002_VRF_NETIO!StreamVerifierBreak

PRIMARY_PROBLEM_CLASS: 0xc4_5002_VRF_NETIO!StreamVerifierBreak

ANALYSIS_SOURCE: KM

FAILURE_ID_HASH_STRING: km:0xc4_5002_vrf_netio!streamverifierbreak

FAILURE_ID_HASH: {fcf5ef21-64f0-ce01-d68b-d6a560b84adb}

Followup: MachineOwner
---------</image.ext>

You can easily achieve first in first out in a LIST_ENTRY. Always insert at the head, always remove the tail.

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@gmail.com
Sent: Monday, August 22, 2016 6:48 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] made a custom queue data structure…need help

because I need a queue which is first in first out…not first in last out…

one question…could it corrupt the stack in a C driver if i don’t declare all of my variables at the top of functions?


NTDEV is sponsored by OSR

Visit the list online at: http:

MONTHLY seminars on crash dump analysis, WDF, Windows internals and software drivers!
Details at http:

To unsubscribe, visit the List Server section of OSR Online at http:</http:></http:></http:>

xxxxx@gmail.com wrote:

the people who designed windows really did ah very bad job…blue screens should not happen this much…

These blue screens are virtually never due to “the people who designed
Windows”. They are due to engineers from other companies writing
drivers and add-in products. The entire kernel subsystem is “trusted
code”, and an exception in “trusted code” is cause for a system halt in
order to limit damage.

If you go back to the very first release of Windows 3.0, when a
processor exception occurred, the dialog box that came up called it an
“Unexpected Application Error”, because they assumed that any crashes
would be due to applications, not due to the operating system. That was
only partly correct, so in Windows 3.1, they politically changed it to
“General Protection Fault”.


Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

this is so annoying…litterally 1000s of fine reinjections, then bam…

BugCheck D1, {3c, 2, 1, fffff801590d3192}
Probably caused by : e1i63x64.sys ( e1i63x64!RECEIVE::RxIndicateNBLs+d4 )

this is obviously some windows bug…no way it will work fine so much, and then randomly crash

googling “RxIndicateNBLs” brings no results…this shit is hardly ever touched…bugs everywhere

Look at the re-injection code in this reference driver:
https://github.com/Microsoft/Windows-driver-samples/tree/master/network/trans/inspect

My guess is you’re skipping a step that you can’t, like cloning the nbl before reinjection. Try to read as much as you can about the Windows Filtering Platform and Callout Drivers.

You’ve got more homework to do, so allow yourself to dig in deep. If you don’t fully understand each line of code in your driver, you’re going to have a lot more problems going forward.

uh…the code works, for 1000s of requests as I have said, and then it randomly blue screens