DRIVER_IRQL_NOT_LESS_OR_EQUAL

I use tdifw1.2 of ntdev.h1.ru
I just got a crash I can’t seem to puzzle out.
Here is the bugcheck info and source.
I’d like to hear any explanation for problem of tdifw.
Thanks in advance.

****************************************************************************
***
*
*
* Bugcheck Analysis
*
*
*
****************************************************************************
***
DRIVER_IRQL_NOT_LESS_OR_EQUAL (d1)
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 kernel debugger is available get stack backtrace.
Arguments:
Arg1: 00000000, memory referenced
Arg2: 00000002, IRQL
Arg3: 00000000, value 0 = read operation, 1 = write operation
Arg4: 00000000, address which referenced memory

Debugging Details:

***** Kernel symbols are WRONG. Please fix symbols to do analysis.

*** ERROR: Symbol file could not be found. Defaulted to export symbols for
tcpip.sys -
*** ERROR: Symbol file could not be found. Defaulted to export symbols for
halmacpi.dll -

READ_ADDRESS: unable to get nt!MmPoolCodeEnd
unable to get nt!MmSpecialPoolEnd
unable to get nt!MmPagedPoolEnd
unable to get nt!MmNonPagedPoolEnd
unable to get nt!MmNonPagedPoolStart
unable to get nt!MmSpecialPoolStart
unable to get nt!MmPagedPoolStart
unable to get nt!MmNonPagedPoolExpansionStart
unable to get nt!MmPoolCodeStart
00000000

CURRENT_IRQL: 2

FAULTING_IP:
+0
00000000 ?? ???

DEFAULT_BUCKET_ID: DRIVER_FAULT

BUGCHECK_STR: 0xD1

LAST_CONTROL_TRANSFER: from 00000000 to 8046987c

STACK_TEXT:
f245f944 00000000 00000000 00000000 00000000 nt!Kei386EoiHelper+0x2ae4

FAILED_INSTRUCTION_ADDRESS:
+0
00000000 ?? ???

FOLLOWUP_IP:
tdifw!tdi_event_receive_datagram+8b [c:\tdifw1.2\src\drv\ev_dg.c @ 83]
bfd6f4ab eb05 jmp tdifw!tdi_event_receive_datagram+0x92 (bfd6f4b2)

FOLLOWUP_NAME: MachineOwner

SYMBOL_NAME: tdifw!tdi_event_receive_datagram+8b

MODULE_NAME: tdifw

IMAGE_NAME: tdifw.sys

DEBUG_FLR_IMAGE_TIMESTAMP: 3fcee114

STACK_COMMAND: kb

BUCKET_ID: WRONG_SYMBOLS

Followup: MachineOwner

// -*- mode: C++; tab-width: 4; indent-tabs-mode: nil -*- (for GNU Emacs)
//
// $Id: ev_dg.c,v 1.2 2002/10/01 12:54:15 dev Exp $

/*
* This file contains TDI_EVENT_RECEIVE_DATAGRAM handler
*/

#include <ntddk.h>
#include <tdikrnl.h>
#include “sock.h”

#include “events.h”
#include “filter.h”
#include “obj_tbl.h”
#include “tdifw.h”

//--------------------------------------------------------------------------


/*
* TDI_EVENT_RECEIVE_DATAGRAM handler
*/

NTSTATUS tdi_event_receive_datagram(
IN PVOID TdiEventContext,
IN LONG SourceAddressLength,
IN PVOID SourceAddress,
IN LONG OptionsLength,
IN PVOID Options,
IN ULONG ReceiveDatagramFlags,
IN ULONG BytesIndicated,
IN ULONG BytesAvailable,
OUT ULONG *BytesTaken,
IN PVOID Tsdu,
OUT PIRP *IoRequestPacket)
{
TDI_EVENT_CONTEXT *ctx = (TDI_EVENT_CONTEXT *)TdiEventContext;
struct ot_entry *ote_addr = NULL;
KIRQL irql;
TA_ADDRESS *remote_addr, *local_addr;
NTSTATUS status;
int ipproto, result = FILTER_DENY;
struct flt_request request;
struct flt_rule rule;

// get local address of address object

ote_addr = ot_find_fileobj(ctx->fileobj, &irql);
if (ote_addr == NULL) {
KdPrint((“[tdifw] tdi_receive_datagram: ot_find_fileobj(0x%x)!\n”,
ctx->fileobj));
goto done;
}

KdPrint((“[tdifw] tdi_event_receive_datagram: addrobj 0x%x\n”,
ctx->fileobj));

// check device object: UDP or RawIP
if (get_original_devobj(ote_addr->devobj, &ipproto) == NULL ||
(ipproto != IPPROTO_UDP && ipproto != IPPROTO_IP)) {
// unknown device object!
KdPrint((“[tdifw] tdi_event_receive_datagram: unknown DeviceObject
0x%x!\n”, ote_addr));
goto done;
}

local_addr = (TA_ADDRESS *)(ote_addr->local_addr);
remote_addr = ((TRANSPORT_ADDRESS *)SourceAddress)->Address;

KdPrint((“[tdifw] tdi_event_receive_datagram(pid:%u): %x:%u -> %x:%u\n”,
ote_addr->pid, ntohl(((TDI_ADDRESS_IP *)(remote_addr->Address))->in_addr),
ntohs(((TDI_ADDRESS_IP *)(remote_addr->Address))->sin_port),
ntohl(((TDI_ADDRESS_IP *)(local_addr->Address))->in_addr),
ntohs(((TDI_ADDRESS_IP *)(local_addr->Address))->sin_port)));

// call quick filter for datagram

memset(&request, 0, sizeof(request));
request.struct_size = sizeof(request);

request.type = TYPE_DATAGRAM;
request.direction = DIRECTION_IN;
request.proto = ipproto;
request.pid = ote_addr->pid;

memcpy(&request.addr.from, &remote_addr->AddressType, sizeof(struct
sockaddr));
memcpy(&request.addr.to, &local_addr->AddressType, sizeof(struct
sockaddr));
request.addr.len = sizeof(struct sockaddr_in);

memset(&rule, 0, sizeof(rule));

result = quick_filter(&request, &rule);

if (rule.log)
log_request(&request);

done:
// cleanup
if (ote_addr != NULL)
KeReleaseSpinLock(&g_ot_hash_guard, irql);

if (result == FILTER_ALLOW) {

return ((PTDI_IND_RECEIVE_DATAGRAM)(ctx->old_handler))
(ctx->old_context, SourceAddressLength, SourceAddress, OptionsLength,
Options, ReceiveDatagramFlags, BytesIndicated, BytesAvailable,
BytesTaken,
Tsdu, IoRequestPacket);

} else
return STATUS_DATA_NOT_ACCEPTED;
}</tdikrnl.h></ntddk.h>

You tried to read data with a null pointer. Since all of the symbols are
invalid the stack traceback is worthless and I’m not going to try to guess
where we are in the code.
You can walk the stack back manually using the debugger and figure out where
you are inthe driver. Or if you built this driver, set the symbol path
correctly in the debugger and it will give you a good isea where you are.

Loren

DRIVER_IRQL_NOT_LESS_OR_EQUAL (d1)
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 kernel debugger is available get stack backtrace.
Arguments:
Arg1: 00000000, memory referenced
Arg2: 00000002, IRQL
Arg3: 00000000, value 0 = read operation, 1 = write operation
Arg4: 00000000, address which referenced memory

I have no experience with TDIFW or NTDEV, but I will try to explain what
causes the bugcheck.

Simply put, it says that you’re trying to access paged out memory when the
paging mechanism is disabled. The paging mechanism is disabled because the
IRQL is higher than the one where the OS can switch tasks, and thus the OS
can not allow the paging task to run. This in turn is because the paging
mechanism will do disk i/o, and that is done from a separate process. [Side
note: if you try to access invalid memory from a high IRQL, the OS will
issue the same error, as there is no good way to tell the difference].

To solve this, you need to figure out what the data that you’re trying to
access. In this case it can be a bit difficult, as the address is zero,
which either means that you tried to dereference a NULL pointer, or that the
code has gone bonkers and for instance filled the stack with zero’s and
tried to return there (this is a strong possibility as the “address that
referenced” is also NULL). Another possibility is that you tried to call a
function pointer with a NULL address.

As Loren just pointed out, it’s hard to say where you are in the OS since
your symboles are busted. I’d recommend that you use web-symbols by setting
your symbol path to contain:
SRV*c:\SYMBOLDIR*http://msdl.microsoft.com/download/symbols;
Of course, SYMBOLDIR should be your choice of where you want to store the
symbols.

By using the MS symbol server, you always have the actual symbols for the
version of Windows you are using, whether you have the latest service pack
and hotfixes, or some old version that was released 6 months back, without
messing about and trying to figure out where the symbols are for that
particular version. It really helps to have accurate symbols.


Mats

-----Original Message-----
From: csjung [mailto:xxxxx@korea.com]
Sent: Wednesday, May 19, 2004 9:05 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] DRIVER_IRQL_NOT_LESS_OR_EQUAL

I use tdifw1.2 of ntdev.h1.ru
I just got a crash I can’t seem to puzzle out.
Here is the bugcheck info and source.
I’d like to hear any explanation for problem of tdifw.
Thanks in advance.

**************************************************************
**************
***
*
*
* Bugcheck Analysis
*
*
*
**************************************************************
**************
***
DRIVER_IRQL_NOT_LESS_OR_EQUAL (d1)
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 kernel debugger is available get stack backtrace.
Arguments:
Arg1: 00000000, memory referenced
Arg2: 00000002, IRQL
Arg3: 00000000, value 0 = read operation, 1 = write operation
Arg4: 00000000, address which referenced memory

Debugging Details:

***** Kernel symbols are WRONG. Please fix symbols to do analysis.

*** ERROR: Symbol file could not be found. Defaulted to
export symbols for
tcpip.sys -
*** ERROR: Symbol file could not be found. Defaulted to
export symbols for
halmacpi.dll -

READ_ADDRESS: unable to get nt!MmPoolCodeEnd
unable to get nt!MmSpecialPoolEnd
unable to get nt!MmPagedPoolEnd
unable to get nt!MmNonPagedPoolEnd
unable to get nt!MmNonPagedPoolStart
unable to get nt!MmSpecialPoolStart
unable to get nt!MmPagedPoolStart
unable to get nt!MmNonPagedPoolExpansionStart
unable to get nt!MmPoolCodeStart
00000000

CURRENT_IRQL: 2

FAULTING_IP:
+0
00000000 ?? ???

DEFAULT_BUCKET_ID: DRIVER_FAULT

BUGCHECK_STR: 0xD1

LAST_CONTROL_TRANSFER: from 00000000 to 8046987c

STACK_TEXT:
f245f944 00000000 00000000 00000000 00000000 nt!Kei386EoiHelper+0x2ae4

FAILED_INSTRUCTION_ADDRESS:
+0
00000000 ?? ???

FOLLOWUP_IP:
tdifw!tdi_event_receive_datagram+8b [c:\tdifw1.2\src\drv\ev_dg.c @ 83]
bfd6f4ab eb05 jmp tdifw!tdi_event_receive_datagram+0x92
(bfd6f4b2)

FOLLOWUP_NAME: MachineOwner

SYMBOL_NAME: tdifw!tdi_event_receive_datagram+8b

MODULE_NAME: tdifw

IMAGE_NAME: tdifw.sys

DEBUG_FLR_IMAGE_TIMESTAMP: 3fcee114

STACK_COMMAND: kb

BUCKET_ID: WRONG_SYMBOLS

Followup: MachineOwner

// -*- mode: C++; tab-width: 4; indent-tabs-mode: nil -*-
(for GNU Emacs)
//
// $Id: ev_dg.c,v 1.2 2002/10/01 12:54:15 dev Exp $

/*
* This file contains TDI_EVENT_RECEIVE_DATAGRAM handler
*/

#include <ntddk.h>
> #include <tdikrnl.h>
> #include “sock.h”
>
> #include “events.h”
> #include “filter.h”
> #include “obj_tbl.h”
> #include “tdifw.h”
>
> //------------------------------------------------------------
> --------------
> –
>
> /*
> * TDI_EVENT_RECEIVE_DATAGRAM handler
> */
>
> NTSTATUS tdi_event_receive_datagram(
> IN PVOID TdiEventContext,
> IN LONG SourceAddressLength,
> IN PVOID SourceAddress,
> IN LONG OptionsLength,
> IN PVOID Options,
> IN ULONG ReceiveDatagramFlags,
> IN ULONG BytesIndicated,
> IN ULONG BytesAvailable,
> OUT ULONG *BytesTaken,
> IN PVOID Tsdu,
> OUT PIRP *IoRequestPacket)
> {
> TDI_EVENT_CONTEXT *ctx = (TDI_EVENT_CONTEXT *)TdiEventContext;
> struct ot_entry *ote_addr = NULL;
> KIRQL irql;
> TA_ADDRESS *remote_addr, *local_addr;
> NTSTATUS status;
> int ipproto, result = FILTER_DENY;
> struct flt_request request;
> struct flt_rule rule;
>
> // get local address of address object
>
> ote_addr = ot_find_fileobj(ctx->fileobj, &irql);
> if (ote_addr == NULL) {
> KdPrint((“[tdifw] tdi_receive_datagram: ot_find_fileobj(0x%x)!\n”,
> ctx->fileobj));
> goto done;
> }
>
> KdPrint((“[tdifw] tdi_event_receive_datagram: addrobj 0x%x\n”,
> ctx->fileobj));
>
> // check device object: UDP or RawIP
> if (get_original_devobj(ote_addr->devobj, &ipproto) == NULL ||
> (ipproto != IPPROTO_UDP && ipproto != IPPROTO_IP)) {
> // unknown device object!
> KdPrint((“[tdifw] tdi_event_receive_datagram: unknown DeviceObject
> 0x%x!\n”, ote_addr));
> goto done;
> }
>
> local_addr = (TA_ADDRESS *)(ote_addr->local_addr);
> remote_addr = ((TRANSPORT_ADDRESS *)SourceAddress)->Address;
>
> KdPrint((“[tdifw] tdi_event_receive_datagram(pid:%u): %x:%u
> -> %x:%u\n”,
> ote_addr->pid, ntohl(((TDI_ADDRESS_IP
> *)(remote_addr->Address))->in_addr),
> ntohs(((TDI_ADDRESS_IP *)(remote_addr->Address))->sin_port),
> ntohl(((TDI_ADDRESS_IP *)(local_addr->Address))->in_addr),
> ntohs(((TDI_ADDRESS_IP *)(local_addr->Address))->sin_port)));
>
> // call quick filter for datagram
>
> memset(&request, 0, sizeof(request));
> request.struct_size = sizeof(request);
>
> request.type = TYPE_DATAGRAM;
> request.direction = DIRECTION_IN;
> request.proto = ipproto;
> request.pid = ote_addr->pid;
>
> memcpy(&request.addr.from, &remote_addr->AddressType, sizeof(struct
> sockaddr));
> memcpy(&request.addr.to, &local_addr->AddressType, sizeof(struct
> sockaddr));
> request.addr.len = sizeof(struct sockaddr_in);
>
> memset(&rule, 0, sizeof(rule));
>
> result = quick_filter(&request, &rule);
>
> if (rule.log)
> log_request(&request);
>
> done:
> // cleanup
> if (ote_addr != NULL)
> KeReleaseSpinLock(&g_ot_hash_guard, irql);
>
> if (result == FILTER_ALLOW) {
>
> return ((PTDI_IND_RECEIVE_DATAGRAM)(ctx->old_handler))
> (ctx->old_context, SourceAddressLength, SourceAddress,
> OptionsLength,
> Options, ReceiveDatagramFlags, BytesIndicated, BytesAvailable,
> BytesTaken,
> Tsdu, IoRequestPacket);
>
> } else
> return STATUS_DATA_NOT_ACCEPTED;
> }
>
>
>
> —
> Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: xxxxx@3dlabs.com
To unsubscribe send a blank email to xxxxx@lists.osr.com</tdikrnl.h></ntddk.h>

In current versions of the debugger, you can always just type !symfix
and it will set it to the default symbol server location (without a
local symbol cache).

Since the original poster decided to violate the rules and cross-post
this over on NTFSD as well (cross posting is prohibited and to do so
someone has to send two separate messages), I’d note that the analysis
over there was quite good in spite of the missing symbols.

NULL pointer dereferences don’t work. I think sometimes we’re making it
too easy - when someone would rather write a long note to NTFSD and copy
it and send it to NTDEV (or vice versa) rather than type “!symfix” and
“!analyze -v” again, we’re doing something wrong.

Regards,

Tony

Tony Mason
Consulting Partner
OSR Open Systems Resources, Inc.
http://www.osr.com

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@3Dlabs.com
Sent: Wednesday, May 19, 2004 5:00 AM
To: ntdev redirect
Subject: RE: [ntdev] DRIVER_IRQL_NOT_LESS_OR_EQUAL

I have no experience with TDIFW or NTDEV, but I will try to explain what
causes the bugcheck.

Simply put, it says that you’re trying to access paged out memory when
the paging mechanism is disabled. The paging mechanism is disabled
because the IRQL is higher than the one where the OS can switch tasks,
and thus the OS can not allow the paging task to run. This in turn is
because the paging mechanism will do disk i/o, and that is done from a
separate process. [Side
note: if you try to access invalid memory from a high IRQL, the OS will
issue the same error, as there is no good way to tell the difference].

To solve this, you need to figure out what the data that you’re trying
to access. In this case it can be a bit difficult, as the address is
zero, which either means that you tried to dereference a NULL pointer,
or that the code has gone bonkers and for instance filled the stack with
zero’s and tried to return there (this is a strong possibility as the
“address that referenced” is also NULL). Another possibility is that you
tried to call a function pointer with a NULL address.

As Loren just pointed out, it’s hard to say where you are in the OS
since your symboles are busted. I’d recommend that you use web-symbols
by setting your symbol path to contain:
SRV*c:\SYMBOLDIR*http://msdl.microsoft.com/download/symbols;
Of course, SYMBOLDIR should be your choice of where you want to store
the symbols.

By using the MS symbol server, you always have the actual symbols for
the version of Windows you are using, whether you have the latest
service pack and hotfixes, or some old version that was released 6
months back, without messing about and trying to figure out where the
symbols are for that particular version. It really helps to have
accurate symbols.


Mats

-----Original Message-----
From: csjung [mailto:xxxxx@korea.com]
Sent: Wednesday, May 19, 2004 9:05 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] DRIVER_IRQL_NOT_LESS_OR_EQUAL

I use tdifw1.2 of ntdev.h1.ru
I just got a crash I can’t seem to puzzle out.
Here is the bugcheck info and source.
I’d like to hear any explanation for problem of tdifw.
Thanks in advance.

**************************************************************
**************
***
*
*
* Bugcheck Analysis
*
*
*
**************************************************************
**************
***
DRIVER_IRQL_NOT_LESS_OR_EQUAL (d1)
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 kernel debugger is available get stack backtrace.
Arguments:
Arg1: 00000000, memory referenced
Arg2: 00000002, IRQL
Arg3: 00000000, value 0 = read operation, 1 = write operation
Arg4: 00000000, address which referenced memory

Debugging Details:

***** Kernel symbols are WRONG. Please fix symbols to do analysis.

*** ERROR: Symbol file could not be found. Defaulted to export
symbols for tcpip.sys -
*** ERROR: Symbol file could not be found. Defaulted to export
symbols for halmacpi.dll -

READ_ADDRESS: unable to get nt!MmPoolCodeEnd unable to get
nt!MmSpecialPoolEnd unable to get nt!MmPagedPoolEnd unable to get
nt!MmNonPagedPoolEnd unable to get nt!MmNonPagedPoolStart unable to
get nt!MmSpecialPoolStart unable to get nt!MmPagedPoolStart unable to
get nt!MmNonPagedPoolExpansionStart unable to get nt!MmPoolCodeStart
00000000

CURRENT_IRQL: 2

FAULTING_IP:
+0
00000000 ?? ???

DEFAULT_BUCKET_ID: DRIVER_FAULT

BUGCHECK_STR: 0xD1

LAST_CONTROL_TRANSFER: from 00000000 to 8046987c

STACK_TEXT:
f245f944 00000000 00000000 00000000 00000000 nt!Kei386EoiHelper+0x2ae4

FAILED_INSTRUCTION_ADDRESS:
+0
00000000 ?? ???

FOLLOWUP_IP:
tdifw!tdi_event_receive_datagram+8b [c:\tdifw1.2\src\drv\ev_dg.c @ 83]
bfd6f4ab eb05 jmp tdifw!tdi_event_receive_datagram+0x92
(bfd6f4b2)

FOLLOWUP_NAME: MachineOwner

SYMBOL_NAME: tdifw!tdi_event_receive_datagram+8b

MODULE_NAME: tdifw

IMAGE_NAME: tdifw.sys

DEBUG_FLR_IMAGE_TIMESTAMP: 3fcee114

STACK_COMMAND: kb

BUCKET_ID: WRONG_SYMBOLS

Followup: MachineOwner

// -*- mode: C++; tab-width: 4; indent-tabs-mode: nil -*- (for GNU
Emacs) // // $Id: ev_dg.c,v 1.2 2002/10/01 12:54:15 dev Exp $

/*
* This file contains TDI_EVENT_RECEIVE_DATAGRAM handler */

#include <ntddk.h>
> #include <tdikrnl.h>
> #include “sock.h”
>
> #include “events.h”
> #include “filter.h”
> #include “obj_tbl.h”
> #include “tdifw.h”
>
> //------------------------------------------------------------
> --------------
> –
>
> /*
> * TDI_EVENT_RECEIVE_DATAGRAM handler
> */
>
> NTSTATUS tdi_event_receive_datagram(
> IN PVOID TdiEventContext,
> IN LONG SourceAddressLength,
> IN PVOID SourceAddress,
> IN LONG OptionsLength,
> IN PVOID Options,
> IN ULONG ReceiveDatagramFlags,
> IN ULONG BytesIndicated,
> IN ULONG BytesAvailable,
> OUT ULONG *BytesTaken,
> IN PVOID Tsdu,
> OUT PIRP *IoRequestPacket)
> {
> TDI_EVENT_CONTEXT *ctx = (TDI_EVENT_CONTEXT *)TdiEventContext;
> struct ot_entry *ote_addr = NULL; KIRQL irql; TA_ADDRESS
> *remote_addr, *local_addr; NTSTATUS status; int ipproto, result =
> FILTER_DENY; struct flt_request request; struct flt_rule rule;
>
> // get local address of address object
>
> ote_addr = ot_find_fileobj(ctx->fileobj, &irql); if (ote_addr ==
> NULL) {
> KdPrint((“[tdifw] tdi_receive_datagram: ot_find_fileobj(0x%x)!\n”,
> ctx->fileobj));
> goto done;
> }
>
> KdPrint((“[tdifw] tdi_event_receive_datagram: addrobj 0x%x\n”,
> ctx->fileobj));
>
> // check device object: UDP or RawIP
> if (get_original_devobj(ote_addr->devobj, &ipproto) == NULL ||
> (ipproto != IPPROTO_UDP && ipproto != IPPROTO_IP)) {
> // unknown device object!
> KdPrint((“[tdifw] tdi_event_receive_datagram: unknown DeviceObject
> 0x%x!\n”, ote_addr));
> goto done;
> }
>
> local_addr = (TA_ADDRESS *)(ote_addr->local_addr); remote_addr =
> ((TRANSPORT_ADDRESS *)SourceAddress)->Address;
>
> KdPrint((“[tdifw] tdi_event_receive_datagram(pid:%u): %x:%u
> -> %x:%u\n”,
> ote_addr->pid, ntohl(((TDI_ADDRESS_IP
> *)(remote_addr->Address))->in_addr),
> ntohs(((TDI_ADDRESS_IP *)(remote_addr->Address))->sin_port),
> ntohl(((TDI_ADDRESS_IP *)(local_addr->Address))->in_addr),
> ntohs(((TDI_ADDRESS_IP *)(local_addr->Address))->sin_port)));
>
> // call quick filter for datagram
>
> memset(&request, 0, sizeof(request)); request.struct_size =
> sizeof(request);
>
> request.type = TYPE_DATAGRAM;
> request.direction = DIRECTION_IN;
> request.proto = ipproto;
> request.pid = ote_addr->pid;
>
> memcpy(&request.addr.from, &remote_addr->AddressType, sizeof(struct
> sockaddr)); memcpy(&request.addr.to, &local_addr->AddressType,
> sizeof(struct sockaddr)); request.addr.len = sizeof(struct
> sockaddr_in);
>
> memset(&rule, 0, sizeof(rule));
>
> result = quick_filter(&request, &rule);
>
> if (rule.log)
> log_request(&request);
>
> done:
> // cleanup
> if (ote_addr != NULL)
> KeReleaseSpinLock(&g_ot_hash_guard, irql);
>
> if (result == FILTER_ALLOW) {
>
> return ((PTDI_IND_RECEIVE_DATAGRAM)(ctx->old_handler))
> (ctx->old_context, SourceAddressLength, SourceAddress,
> OptionsLength,
> Options, ReceiveDatagramFlags, BytesIndicated, BytesAvailable,
> BytesTaken,
> Tsdu, IoRequestPacket);
>
> } else
> return STATUS_DATA_NOT_ACCEPTED;
> }
>
>
>
> —
> Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: xxxxx@3dlabs.com
To unsubscribe send a blank email to xxxxx@lists.osr.com


Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: xxxxx@osr.com
To unsubscribe send a blank email to xxxxx@lists.osr.com</tdikrnl.h></ntddk.h>

Tony,

I agree that cross posting is a waste of other peoples time.

Of course, with modern mail software, you can usually “resend” the same
e-mail to a new address, which isn’t much effort at all.

Thanks for pointing out the !symfix, I didn’t know about that. Quite a
useful thing to have…

Still, I think the problem the poster had was to understand what the problem
was, not to get correct symbols, even though having correct symbols is
generally quite helpful.


Mats

-----Original Message-----
From: Tony Mason [mailto:xxxxx@osr.com]
Sent: Wednesday, May 19, 2004 10:38 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] DRIVER_IRQL_NOT_LESS_OR_EQUAL

In current versions of the debugger, you can always just type !symfix
and it will set it to the default symbol server location (without a
local symbol cache).

Since the original poster decided to violate the rules and cross-post
this over on NTFSD as well (cross posting is prohibited and to do so
someone has to send two separate messages), I’d note that the analysis
over there was quite good in spite of the missing symbols.

NULL pointer dereferences don’t work. I think sometimes
we’re making it
too easy - when someone would rather write a long note to
NTFSD and copy
it and send it to NTDEV (or vice versa) rather than type “!symfix” and
“!analyze -v” again, we’re doing something wrong.

Regards,

Tony

Tony Mason
Consulting Partner
OSR Open Systems Resources, Inc.
http://www.osr.com

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@3Dlabs.com
Sent: Wednesday, May 19, 2004 5:00 AM
To: ntdev redirect
Subject: RE: [ntdev] DRIVER_IRQL_NOT_LESS_OR_EQUAL

I have no experience with TDIFW or NTDEV, but I will try to
explain what
causes the bugcheck.

Simply put, it says that you’re trying to access paged out memory when
the paging mechanism is disabled. The paging mechanism is disabled
because the IRQL is higher than the one where the OS can switch tasks,
and thus the OS can not allow the paging task to run. This in turn is
because the paging mechanism will do disk i/o, and that is done from a
separate process. [Side
note: if you try to access invalid memory from a high IRQL,
the OS will
issue the same error, as there is no good way to tell the
difference].

To solve this, you need to figure out what the data that you’re trying
to access. In this case it can be a bit difficult, as the address is
zero, which either means that you tried to dereference a NULL pointer,
or that the code has gone bonkers and for instance filled the
stack with
zero’s and tried to return there (this is a strong possibility as the
“address that referenced” is also NULL). Another possibility
is that you
tried to call a function pointer with a NULL address.

As Loren just pointed out, it’s hard to say where you are in the OS
since your symboles are busted. I’d recommend that you use web-symbols
by setting your symbol path to contain:
SRV*c:\SYMBOLDIR*http://msdl.microsoft.com/download/symbols;
Of course, SYMBOLDIR should be your choice of where you want to store
the symbols.

By using the MS symbol server, you always have the actual symbols for
the version of Windows you are using, whether you have the latest
service pack and hotfixes, or some old version that was released 6
months back, without messing about and trying to figure out where the
symbols are for that particular version. It really helps to have
accurate symbols.


Mats

> -----Original Message-----
> From: csjung [mailto:xxxxx@korea.com]
> Sent: Wednesday, May 19, 2004 9:05 AM
> To: Windows System Software Devs Interest List
> Subject: [ntdev] DRIVER_IRQL_NOT_LESS_OR_EQUAL
>
>
> I use tdifw1.2 of ntdev.h1.ru
> I just got a crash I can’t seem to puzzle out.
> Here is the bugcheck info and source.
> I’d like to hear any explanation for problem of tdifw.
> Thanks in advance.
>
> **************************************************************
> **************
> ***
> *
> *
> * Bugcheck Analysis
> *
> *
> *
> **************************************************************
> **************
> ***
> DRIVER_IRQL_NOT_LESS_OR_EQUAL (d1)
> 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 kernel debugger is available get stack backtrace.
> Arguments:
> Arg1: 00000000, memory referenced
> Arg2: 00000002, IRQL
> Arg3: 00000000, value 0 = read operation, 1 = write operation
> Arg4: 00000000, address which referenced memory
>
> Debugging Details:
> ------------------
>
> ***** Kernel symbols are WRONG. Please fix symbols to do analysis.
>
> *** ERROR: Symbol file could not be found. Defaulted to export
> symbols for tcpip.sys -
> *** ERROR: Symbol file could not be found. Defaulted to export
> symbols for halmacpi.dll -
>
> READ_ADDRESS: unable to get nt!MmPoolCodeEnd unable to get
> nt!MmSpecialPoolEnd unable to get nt!MmPagedPoolEnd unable to get
> nt!MmNonPagedPoolEnd unable to get nt!MmNonPagedPoolStart unable to
> get nt!MmSpecialPoolStart unable to get nt!MmPagedPoolStart
unable to
> get nt!MmNonPagedPoolExpansionStart unable to get
nt!MmPoolCodeStart
> 00000000
>
> CURRENT_IRQL: 2
>
> FAULTING_IP:
> +0
> 00000000 ?? ???
>
> DEFAULT_BUCKET_ID: DRIVER_FAULT
>
> BUGCHECK_STR: 0xD1
>
> LAST_CONTROL_TRANSFER: from 00000000 to 8046987c
>
> STACK_TEXT:
> f245f944 00000000 00000000 00000000 00000000
nt!Kei386EoiHelper+0x2ae4
>
>
> FAILED_INSTRUCTION_ADDRESS:
> +0
> 00000000 ?? ???
>
> FOLLOWUP_IP:
> tdifw!tdi_event_receive_datagram+8b
[c:\tdifw1.2\src\drv\ev_dg.c @ 83]
> bfd6f4ab eb05 jmp tdifw!tdi_event_receive_datagram+0x92
> (bfd6f4b2)
>
> FOLLOWUP_NAME: MachineOwner
>
> SYMBOL_NAME: tdifw!tdi_event_receive_datagram+8b
>
> MODULE_NAME: tdifw
>
> IMAGE_NAME: tdifw.sys
>
> DEBUG_FLR_IMAGE_TIMESTAMP: 3fcee114
>
> STACK_COMMAND: kb
>
> BUCKET_ID: WRONG_SYMBOLS
>
> Followup: MachineOwner
> ---------
>
> // -*- mode: C++; tab-width: 4; indent-tabs-mode: nil -*- (for GNU
> Emacs) // // $Id: ev_dg.c,v 1.2 2002/10/01 12:54:15 dev Exp $
>
> /*
> * This file contains TDI_EVENT_RECEIVE_DATAGRAM handler */
>
> #include <ntddk.h>
> > #include <tdikrnl.h>
> > #include “sock.h”
> >
> > #include “events.h”
> > #include “filter.h”
> > #include “obj_tbl.h”
> > #include “tdifw.h”
> >
> > //------------------------------------------------------------
> > --------------
> > –
> >
> > /*
> > * TDI_EVENT_RECEIVE_DATAGRAM handler
> > */
> >
> > NTSTATUS tdi_event_receive_datagram(
> > IN PVOID TdiEventContext,
> > IN LONG SourceAddressLength,
> > IN PVOID SourceAddress,
> > IN LONG OptionsLength,
> > IN PVOID Options,
> > IN ULONG ReceiveDatagramFlags,
> > IN ULONG BytesIndicated,
> > IN ULONG BytesAvailable,
> > OUT ULONG *BytesTaken,
> > IN PVOID Tsdu,
> > OUT PIRP *IoRequestPacket)
> > {
> > TDI_EVENT_CONTEXT *ctx = (TDI_EVENT_CONTEXT *)TdiEventContext;
> > struct ot_entry *ote_addr = NULL; KIRQL irql; TA_ADDRESS
> > *remote_addr, *local_addr; NTSTATUS status; int ipproto, result =
> > FILTER_DENY; struct flt_request request; struct flt_rule rule;
> >
> > // get local address of address object
> >
> > ote_addr = ot_find_fileobj(ctx->fileobj, &irql); if (ote_addr ==
> > NULL) {
> > KdPrint((“[tdifw] tdi_receive_datagram: ot_find_fileobj(0x%x)!\n”,
> > ctx->fileobj));
> > goto done;
> > }
> >
> > KdPrint((“[tdifw] tdi_event_receive_datagram: addrobj 0x%x\n”,
> > ctx->fileobj));
> >
> > // check device object: UDP or RawIP
> > if (get_original_devobj(ote_addr->devobj, &ipproto) == NULL ||
> > (ipproto != IPPROTO_UDP && ipproto != IPPROTO_IP)) {
> > // unknown device object!
> > KdPrint((“[tdifw] tdi_event_receive_datagram: unknown
> DeviceObject
> > 0x%x!\n”, ote_addr));
> > goto done;
> > }
> >
> > local_addr = (TA_ADDRESS *)(ote_addr->local_addr); remote_addr =
> > ((TRANSPORT_ADDRESS *)SourceAddress)->Address;
> >
> > KdPrint((“[tdifw] tdi_event_receive_datagram(pid:%u): %x:%u
> > -> %x:%u\n”,
> > ote_addr->pid, ntohl(((TDI_ADDRESS_IP
> > *)(remote_addr->Address))->in_addr),
> > ntohs(((TDI_ADDRESS_IP *)(remote_addr->Address))->sin_port),
> > ntohl(((TDI_ADDRESS_IP *)(local_addr->Address))->in_addr),
> > ntohs(((TDI_ADDRESS_IP *)(local_addr->Address))->sin_port)));
> >
> > // call quick filter for datagram
> >
> > memset(&request, 0, sizeof(request)); request.struct_size =
> > sizeof(request);
> >
> > request.type = TYPE_DATAGRAM;
> > request.direction = DIRECTION_IN;
> > request.proto = ipproto;
> > request.pid = ote_addr->pid;
> >
> > memcpy(&request.addr.from, &remote_addr->AddressType,
> sizeof(struct
> > sockaddr)); memcpy(&request.addr.to, &local_addr->AddressType,
> > sizeof(struct sockaddr)); request.addr.len = sizeof(struct
> > sockaddr_in);
> >
> > memset(&rule, 0, sizeof(rule));
> >
> > result = quick_filter(&request, &rule);
> >
> > if (rule.log)
> > log_request(&request);
> >
> > done:
> > // cleanup
> > if (ote_addr != NULL)
> > KeReleaseSpinLock(&g_ot_hash_guard, irql);
> >
> > if (result == FILTER_ALLOW) {
> >
> > return ((PTDI_IND_RECEIVE_DATAGRAM)(ctx->old_handler))
> > (ctx->old_context, SourceAddressLength, SourceAddress,
> > OptionsLength,
> > Options, ReceiveDatagramFlags, BytesIndicated, BytesAvailable,
> > BytesTaken,
> > Tsdu, IoRequestPacket);
> >
> > } else
> > return STATUS_DATA_NOT_ACCEPTED;
> > }
> >
> >
> >
> > —
> > Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: xxxxx@3dlabs.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: xxxxx@osr.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
>
>
> —
> Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: xxxxx@3dlabs.com
To unsubscribe send a blank email to xxxxx@lists.osr.com</tdikrnl.h></ntddk.h>

The crash is due to calling NULL function pointer.
I can bet you are calling ctx->old_handler after it is set to NULL. I
will explain the flow when this could happen.

  1. App/Afd Sets RecvData gram handler to func x.
  2. You store the func x and set to func y.
  3. Stack sends a datagram to func y.
  4. before function y executes, app decides to close the address object
    so it sets the recv data gram handler to NULL.
  5. you store the NULL pointer in your structure.
  6. now your function y executes and calls the original function which is
    x.
  7. Boom you crash.

Perfect code to crash.
Add a null function check before calling the function. Ctx->old_handler
everything will work.

-Srin.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of csjung
Sent: Wednesday, May 19, 2004 1:05 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] DRIVER_IRQL_NOT_LESS_OR_EQUAL

I use tdifw1.2 of ntdev.h1.ru
I just got a crash I can’t seem to puzzle out.
Here is the bugcheck info and source.
I’d like to hear any explanation for problem of tdifw.
Thanks in advance.

************************************************************************
****
***
*
*
* Bugcheck Analysis
*
*
*
************************************************************************
****
***
DRIVER_IRQL_NOT_LESS_OR_EQUAL (d1)
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 kernel debugger is
available get stack backtrace.
Arguments:
Arg1: 00000000, memory referenced
Arg2: 00000002, IRQL
Arg3: 00000000, value 0 = read operation, 1 = write operation
Arg4: 00000000, address which referenced memory

Debugging Details:

***** Kernel symbols are WRONG. Please fix symbols to do analysis.

*** ERROR: Symbol file could not be found. Defaulted to export symbols
for tcpip.sys -
*** ERROR: Symbol file could not be found. Defaulted to export symbols
for halmacpi.dll -

READ_ADDRESS: unable to get nt!MmPoolCodeEnd
unable to get nt!MmSpecialPoolEnd
unable to get nt!MmPagedPoolEnd
unable to get nt!MmNonPagedPoolEnd
unable to get nt!MmNonPagedPoolStart
unable to get nt!MmSpecialPoolStart
unable to get nt!MmPagedPoolStart
unable to get nt!MmNonPagedPoolExpansionStart
unable to get nt!MmPoolCodeStart
00000000

CURRENT_IRQL: 2

FAULTING_IP:
+0
00000000 ?? ???

DEFAULT_BUCKET_ID: DRIVER_FAULT

BUGCHECK_STR: 0xD1

LAST_CONTROL_TRANSFER: from 00000000 to 8046987c

STACK_TEXT:
f245f944 00000000 00000000 00000000 00000000 nt!Kei386EoiHelper+0x2ae4

FAILED_INSTRUCTION_ADDRESS:
+0
00000000 ?? ???

FOLLOWUP_IP:
tdifw!tdi_event_receive_datagram+8b [c:\tdifw1.2\src\drv\ev_dg.c @ 83]
bfd6f4ab eb05 jmp tdifw!tdi_event_receive_datagram+0x92 (bfd6f4b2)

FOLLOWUP_NAME: MachineOwner

SYMBOL_NAME: tdifw!tdi_event_receive_datagram+8b

MODULE_NAME: tdifw

IMAGE_NAME: tdifw.sys

DEBUG_FLR_IMAGE_TIMESTAMP: 3fcee114

STACK_COMMAND: kb

BUCKET_ID: WRONG_SYMBOLS

Followup: MachineOwner

// -*- mode: C++; tab-width: 4; indent-tabs-mode: nil -*- (for GNU
Emacs) // // $Id: ev_dg.c,v 1.2 2002/10/01 12:54:15 dev Exp $

/*
* This file contains TDI_EVENT_RECEIVE_DATAGRAM handler
*/

#include <ntddk.h>
#include <tdikrnl.h>
#include “sock.h”

#include “events.h”
#include “filter.h”
#include “obj_tbl.h”
#include “tdifw.h”

//----------------------------------------------------------------------
----


/*
* TDI_EVENT_RECEIVE_DATAGRAM handler
*/

NTSTATUS tdi_event_receive_datagram(
IN PVOID TdiEventContext,
IN LONG SourceAddressLength,
IN PVOID SourceAddress,
IN LONG OptionsLength,
IN PVOID Options,
IN ULONG ReceiveDatagramFlags,
IN ULONG BytesIndicated,
IN ULONG BytesAvailable,
OUT ULONG *BytesTaken,
IN PVOID Tsdu,
OUT PIRP *IoRequestPacket)
{
TDI_EVENT_CONTEXT *ctx = (TDI_EVENT_CONTEXT *)TdiEventContext; struct
ot_entry *ote_addr = NULL; KIRQL irql; TA_ADDRESS *remote_addr,
*local_addr; NTSTATUS status; int ipproto, result = FILTER_DENY;
struct flt_request request; struct flt_rule rule;

// get local address of address object

ote_addr = ot_find_fileobj(ctx->fileobj, &irql);
if (ote_addr == NULL) {
KdPrint((“[tdifw] tdi_receive_datagram: ot_find_fileobj(0x%x)!\n”,
ctx->fileobj));
goto done;
}

KdPrint((“[tdifw] tdi_event_receive_datagram: addrobj 0x%x\n”,
ctx->fileobj));

// check device object: UDP or RawIP
if (get_original_devobj(ote_addr->devobj, &ipproto) == NULL ||
(ipproto != IPPROTO_UDP && ipproto != IPPROTO_IP)) {
// unknown device object!
KdPrint((“[tdifw] tdi_event_receive_datagram: unknown DeviceObject
0x%x!\n”, ote_addr));
goto done;
}

local_addr = (TA_ADDRESS *)(ote_addr->local_addr);
remote_addr = ((TRANSPORT_ADDRESS )SourceAddress)->Address;

KdPrint((“[tdifw] tdi_event_receive_datagram(pid:%u): %x:%u ->
%x:%u\n”, ote_addr->pid, ntohl(((TDI_ADDRESS_IP
)(remote_addr->Address))->in_addr),
ntohs(((TDI_ADDRESS_IP *)(remote_addr->Address))->sin_port),
ntohl(((TDI_ADDRESS_IP *)(local_addr->Address))->in_addr),
ntohs(((TDI_ADDRESS_IP *)(local_addr->Address))->sin_port)));

// call quick filter for datagram

memset(&request, 0, sizeof(request));
request.struct_size = sizeof(request);

request.type = TYPE_DATAGRAM;
request.direction = DIRECTION_IN;
request.proto = ipproto;
request.pid = ote_addr->pid;

memcpy(&request.addr.from, &remote_addr->AddressType, sizeof(struct
sockaddr)); memcpy(&request.addr.to, &local_addr->AddressType,
sizeof(struct sockaddr)); request.addr.len = sizeof(struct
sockaddr_in);

memset(&rule, 0, sizeof(rule));

result = quick_filter(&request, &rule);

if (rule.log)
log_request(&request);

done:
// cleanup
if (ote_addr != NULL)
KeReleaseSpinLock(&g_ot_hash_guard, irql);

if (result == FILTER_ALLOW) {

return ((PTDI_IND_RECEIVE_DATAGRAM)(ctx->old_handler))
(ctx->old_context, SourceAddressLength, SourceAddress, OptionsLength,
Options, ReceiveDatagramFlags, BytesIndicated, BytesAvailable,
BytesTaken,
Tsdu, IoRequestPacket);

} else
return STATUS_DATA_NOT_ACCEPTED;
}


Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: xxxxx@nai.com
To unsubscribe send a blank email to xxxxx@lists.osr.com</tdikrnl.h></ntddk.h>

Thanks for your showing an interest in my question!

I add a null function check.
If ctx->old_handler is null, I just returned STATUS_DATA_NOT_ACCEPTED.
Is it right?

Tanks in advance.

—source-code—
done:
// cleanup
if (ote_addr != NULL)
KeReleaseSpinLock(&g_ot_hash_guard, irql);

if(ctx->old_handler == NULL) return STATUS_DATA_NOT_ACCEPTED;

if (result == FILTER_ALLOW) {

return ((PTDI_IND_RECEIVE_DATAGRAM)(ctx->old_handler))
(ctx->old_context, SourceAddressLength, SourceAddress, OptionsLength,
Options, ReceiveDatagramFlags, BytesIndicated, BytesAvailable,
BytesTaken,
Tsdu, IoRequestPacket);

} else
return STATUS_DATA_NOT_ACCEPTED;
}

wrote in message news:xxxxx@ntdev…
The crash is due to calling NULL function pointer.
I can bet you are calling ctx->old_handler after it is set to NULL. I
will explain the flow when this could happen.

1. App/Afd Sets RecvData gram handler to func x.
2. You store the func x and set to func y.
3. Stack sends a datagram to func y.
4. before function y executes, app decides to close the address object
so it sets the recv data gram handler to NULL.
5. you store the NULL pointer in your structure.
6. now your function y executes and calls the original function which is
x.
7. Boom you crash.

Perfect code to crash.
Add a null function check before calling the function. Ctx->old_handler
everything will work.

-Srin.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of csjung
Sent: Wednesday, May 19, 2004 1:05 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] DRIVER_IRQL_NOT_LESS_OR_EQUAL

I use tdifw1.2 of ntdev.h1.ru
I just got a crash I can’t seem to puzzle out.
Here is the bugcheck info and source.
I’d like to hear any explanation for problem of tdifw.
Thanks in advance.






Bugcheck Analysis



*******


DRIVER_IRQL_NOT_LESS_OR_EQUAL (d1)
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 kernel debugger is
available get stack backtrace.
Arguments:
Arg1: 00000000, memory referenced
Arg2: 00000002, IRQL
Arg3: 00000000, value 0 = read operation, 1 = write operation
Arg4: 00000000, address which referenced memory

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

Kernel symbols are WRONG. Please fix symbols to do analysis.

ERROR: Symbol file could not be found. Defaulted to export symbols
for tcpip.sys -
ERROR: Symbol file could not be found. Defaulted to export symbols
for halmacpi.dll -

READ_ADDRESS: unable to get nt!MmPoolCodeEnd
unable to get nt!MmSpecialPoolEnd
unable to get nt!MmPagedPoolEnd
unable to get nt!MmNonPagedPoolEnd
unable to get nt!MmNonPagedPoolStart
unable to get nt!MmSpecialPoolStart
unable to get nt!MmPagedPoolStart
unable to get nt!MmNonPagedPoolExpansionStart
unable to get nt!MmPoolCodeStart
00000000

CURRENT_IRQL: 2

FAULTING_IP:
+0
00000000 ?? ???

DEFAULT_BUCKET_ID: DRIVER_FAULT

BUGCHECK_STR: 0xD1

LAST_CONTROL_TRANSFER: from 00000000 to 8046987c

STACK_TEXT:
f245f944 00000000 00000000 00000000 00000000 nt!Kei386EoiHelper+0x2ae4

FAILED_INSTRUCTION_ADDRESS:
+0
00000000 ?? ???

FOLLOWUP_IP:
tdifw!tdi_event_receive_datagram+8b [c:\tdifw1.2\src\drv\ev_dg.c @ 83]
bfd6f4ab eb05 jmp tdifw!tdi_event_receive_datagram+0x92 (bfd6f4b2)

FOLLOWUP_NAME: MachineOwner

SYMBOL_NAME: tdifw!tdi_event_receive_datagram+8b

MODULE_NAME: tdifw

IMAGE_NAME: tdifw.sys

DEBUG_FLR_IMAGE_TIMESTAMP: 3fcee114

STACK_COMMAND: kb

BUCKET_ID: WRONG_SYMBOLS

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

// -- mode: C++; tab-width: 4; indent-tabs-mode: nil -- (for GNU
Emacs) // // $Id: ev_dg.c,v 1.2 2002/10/01 12:54:15 dev Exp $

/*
* This file contains TDI_EVENT_RECEIVE_DATAGRAM handler
/

#include <ntddk.h>
#include <tdikrnl.h>
#include “sock.h”

#include “events.h”
#include “filter.h”
#include “obj_tbl.h”
#include “tdifw.h”

//----------------------------------------------------------------------
----


/

* TDI_EVENT_RECEIVE_DATAGRAM handler
*/

NTSTATUS tdi_event_receive_datagram(
IN PVOID TdiEventContext,
IN LONG SourceAddressLength,
IN PVOID SourceAddress,
IN LONG OptionsLength,
IN PVOID Options,
IN ULONG ReceiveDatagramFlags,
IN ULONG BytesIndicated,
IN ULONG BytesAvailable,
OUT ULONG *BytesTaken,
IN PVOID Tsdu,
OUT PIRP *IoRequestPacket)
{
TDI_EVENT_CONTEXT *ctx = (TDI_EVENT_CONTEXT *)TdiEventContext; struct
ot_entry *ote_addr = NULL; KIRQL irql; TA_ADDRESS *remote_addr,
*local_addr; NTSTATUS status; int ipproto, result = FILTER_DENY;
struct flt_request request; struct flt_rule rule;

// get local address of address object

ote_addr = ot_find_fileobj(ctx->fileobj, &irql);
if (ote_addr == NULL) {
KdPrint((“[tdifw] tdi_receive_datagram: ot_find_fileobj(0x%x)!\n”,
ctx->fileobj));
goto done;
}

KdPrint((“[tdifw] tdi_event_receive_datagram: addrobj 0x%x\n”,
ctx->fileobj));

// check device object: UDP or RawIP
if (get_original_devobj(ote_addr->devobj, &ipproto) == NULL ||
(ipproto != IPPROTO_UDP && ipproto != IPPROTO_IP)) {
// unknown device object!
KdPrint((“[tdifw] tdi_event_receive_datagram: unknown DeviceObject
0x%x!\n”, ote_addr));
goto done;
}

local_addr = (TA_ADDRESS *)(ote_addr->local_addr);
remote_addr = ((TRANSPORT_ADDRESS )SourceAddress)->Address;

KdPrint((“[tdifw] tdi_event_receive_datagram(pid:%u): %x:%u ->
%x:%u\n”, ote_addr->pid, ntohl(((TDI_ADDRESS_IP
)(remote_addr->Address))->in_addr),
ntohs(((TDI_ADDRESS_IP *)(remote_addr->Address))->sin_port),
ntohl(((TDI_ADDRESS_IP *)(local_addr->Address))->in_addr),
ntohs(((TDI_ADDRESS_IP *)(local_addr->Address))->sin_port)));

// call quick filter for datagram

memset(&request, 0, sizeof(request));
request.struct_size = sizeof(request);

request.type = TYPE_DATAGRAM;
request.direction = DIRECTION_IN;
request.proto = ipproto;
request.pid = ote_addr->pid;

memcpy(&request.addr.from, &remote_addr->AddressType, sizeof(struct
sockaddr)); memcpy(&request.addr.to, &local_addr->AddressType,
sizeof(struct sockaddr)); request.addr.len = sizeof(struct
sockaddr_in);

memset(&rule, 0, sizeof(rule));

result = quick_filter(&request, &rule);

if (rule.log)
log_request(&request);

done:
// cleanup
if (ote_addr != NULL)
KeReleaseSpinLock(&g_ot_hash_guard, irql);

if (result == FILTER_ALLOW) {

return ((PTDI_IND_RECEIVE_DATAGRAM)(ctx->old_handler))
(ctx->old_context, SourceAddressLength, SourceAddress, OptionsLength,
Options, ReceiveDatagramFlags, BytesIndicated, BytesAvailable,
BytesTaken,
Tsdu, IoRequestPacket);

} else
return STATUS_DATA_NOT_ACCEPTED;
}


Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: xxxxx@nai.com
To unsubscribe send a blank email to xxxxx@lists.osr.com</tdikrnl.h></ntddk.h>