Filter Hook [Device Drivers]

Prev: PacketStackSize
Next: Loading winusb.sys in Window XP

From: hanzhu on 6 Aug 2006 22:38

IIRC, IP filter driver should process these packets through the callback
routine instead of submitting the IRP to the lower tcpip protocol
driver. Why do you need to pass the IRPs and wait for its completion?

x856256(a)yahoo.com ?:
> Hello,
>
> Either queueing the job or doing it asynchronously I will have to do
> the job in another thread, and wait for the process of the packet to
> finish (in order to return the drop, forward or pass reply), and this
> is exactly where my problem began, when I tried to use the
> KeWaitForSingleObject function.
> So let me ask this again: How can I use this wait function, or any
> other substitution that will allow me process the packet on another
> thread (queued or not) and wait for it to finish processing in order to
> return the value?
>
> Thanks,
> Guy
>
> Doron Holan [MS] wrote:
>> you can't reduce IRQL inline, you can only raise it and then lower it. if
>> you truly want to synchronously process soemthing, then queue it to a work
>> item. if you want your filter to not negatively affect performance, learn
>> how to process the results in the completion routine asynchronously
>>
>> d
>>
>> --
>> Please do not send e-mail directly to this alias. this alias is for
>> newsgroup purposes only.
>> This posting is provided "AS IS" with no warranties, and confers no rights.
>>
>>
>> <x856256(a)yahoo.com> wrote in message
>> news:1154873993.596484.241370(a)i42g2000cwa.googlegroups.com...
>>> No,
>>>
>>> The code is not taking any spinlocks.
>>> Anyone has an idea how can I reduce the IRQL level inside the filter
>>> hook function?
>>>
>>> Thanks,
>>> Guy
>>>
>>> Don Burn wrote:
>>>> You cannot call a lot of functions at DISPATCH_LEVEL. I am not well
>>>> versed
>>>> in filter hooks, so you need to determine if the raising to DISPATCH is
>>>> avoidable. For instance, if the code takes a spinlock, could it take an
>>>> ERESOURCE instead.
>>>>
>>>>
>>>> --
>>>> Don Burn (MVP, Windows DDK)
>>>> Windows 2k/XP/2k3 Filesystem and Driver Consulting
>>>> http://www.windrvr.com
>>>> Remove StopSpam from the email to reply
>>>>
>>>>
>>>>
>>>> <x856256(a)yahoo.com> wrote in message
>>>> news:1154861486.219608.122660(a)m73g2000cwd.googlegroups.com...
>>>>> Hello and thanks Don for the answer.
>>>>>
>>>>> It is running in IRQL_DISPATCH, I will try to reduce it and see what
>>>>> happens.
>>>>>
>>>>> Thanks,
>>>>> Guy
>>>>>
>>>>> Don Burn wrote:
>>>>>> A filter hook driver should not have an interrupt handler it is only
>>>>>> concerned with packets as they are presented to it. You should not
>>>>>> try
>>>>>> to
>>>>>> use IoConnectInterrupt with a software interrupt.
>>>>>>
>>>>>> What IRQL are you running at when you crash, a common problem here
>>>>>> would
>>>>>> be
>>>>>> calling the functions you mentioned at IRQL_DISPATCH or higher.
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Don Burn (MVP, Windows DDK)
>>>>>> Windows 2k/XP/2k3 Filesystem and Driver Consulting
>>>>>> http://www.windrvr.com
>>>>>> Remove StopSpam from the email to reply
>>>>>>
>>>>>>
>>>>>>
>>>>>> <x856256(a)yahoo.com> wrote in message
>>>>>> news:1154814887.364085.142850(a)n13g2000cwa.googlegroups.com...
>>>>>>> Hi,
>>>>>>>
>>>>>>> Drivers are very new to me, can someone help me with the next issue
>>>>>>> please:
>>>>>>>
>>>>>>> I have tried to set up a Filter Hook driver.
>>>>>>> I took an example code from codeproject (DrvFltIp) and it works ok
>>>>>>> on
>>>>>>> my computer (Windows XP).
>>>>>>>
>>>>>>> When I try to process the packets more thoroughly than in this
>>>>>>> example
>>>>>>> code, my computer crashed (freezes or restarts immediately).
>>>>>>> The crash happens when I do something that involves a
>>>>>>> KeWaitForSingleObject or a KeDelayExecutionThread call (but I am not
>>>>>>> sure these are the only scenarios that cause a crash).
>>>>>>>
>>>>>>> I looked in the dump file with WinDbg after the crash and saw that
>>>>>>> one
>>>>>>> of the last actions of the kernel were sending an interrupt and
>>>>>>> afterwards an exception. So my guess was that the kernel is sending
>>>>>>> a
>>>>>>> trap that was sent to it by the hardware to my driver to handle, but
>>>>>>> since I didn't set up an interrupt call back function, an exception
>>>>>>> is
>>>>>>> raised.
>>>>>>> The next thing I did was to try and set up an interrupt call back
>>>>>>> function, but this also caused a similar crash to the system (when I
>>>>>>> tried to pull out the parameters that I have to pass to the function
>>>>>>> "IoConnectInterrupt" from the isrStack). I tried to call the
>>>>>>> function
>>>>>>> "IoConnectInterrupt" from the function
>>>>>>> "DriverObject->MajorFunction[IRP_MJ_CREATE]" when got
>>>>>>> "IRP_MJ_CREATE"
>>>>>>> in "irpStack->MajorFunction" or when I got "IRP_MN_START_DEVICE IRP"
>>>>>>> in
>>>>>>> "irpStack->MinorFunction". When I tried even to access the parameter
>>>>>>> "irpStack->Parameters->StartDevice.AllocatedResourcesTranslated->Count"
>>>>>>> (even without calling "IoConnectInterrupt") it caused a crash.
>>>>>>>
>>>>>>> If anyone can help me understand what I am doing wrong, and why I am
>>>>>>> getting all these crashes I would be grateful.
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Guy
>>>>>>>
>

From: x856256 on 7 Aug 2006 01:37

I tried at the beginning to process the packets on the same thread, but
it caused the system to crash every time.
Since I found it very hard to program in kernel-mode, and even harder
to debug it, I wanted to let a user-mode program process the packet and
wait till it finishes in order to return. Was that a bad idea? If it is
a bad idea, it means I should do all the processing in the driver, and
on the same thread. In such a scenario I will have to synchronize
somewhere because my packet process depends on other packets that were
previously processed (so I must have a synchronized queue of packets)
and again I have the same problem as the first one (or do I ?)

Thanks,
Guy

hanzhu wrote:
> IIRC, IP filter driver should process these packets through the callback
> routine instead of submitting the IRP to the lower tcpip protocol
> driver. Why do you need to pass the IRPs and wait for its completion?
>
>
> x856256(a)yahoo.com Ð´µÀ:
> > Hello,
> >
> > Either queueing the job or doing it asynchronously I will have to do
> > the job in another thread, and wait for the process of the packet to
> > finish (in order to return the drop, forward or pass reply), and this
> > is exactly where my problem began, when I tried to use the
> > KeWaitForSingleObject function.
> > So let me ask this again: How can I use this wait function, or any
> > other substitution that will allow me process the packet on another
> > thread (queued or not) and wait for it to finish processing in order to
> > return the value?
> >
> > Thanks,
> > Guy
> >
> > Doron Holan [MS] wrote:
> >> you can't reduce IRQL inline, you can only raise it and then lower it. if
> >> you truly want to synchronously process soemthing, then queue it to a work
> >> item. if you want your filter to not negatively affect performance, learn
> >> how to process the results in the completion routine asynchronously
> >>
> >> d
> >>
> >> --
> >> Please do not send e-mail directly to this alias. this alias is for
> >> newsgroup purposes only.
> >> This posting is provided "AS IS" with no warranties, and confers no rights.
> >>
> >>
> >> <x856256(a)yahoo.com> wrote in message
> >> news:1154873993.596484.241370(a)i42g2000cwa.googlegroups.com...
> >>> No,
> >>>
> >>> The code is not taking any spinlocks.
> >>> Anyone has an idea how can I reduce the IRQL level inside the filter
> >>> hook function?
> >>>
> >>> Thanks,
> >>> Guy
> >>>
> >>> Don Burn wrote:
> >>>> You cannot call a lot of functions at DISPATCH_LEVEL. I am not well
> >>>> versed
> >>>> in filter hooks, so you need to determine if the raising to DISPATCH is
> >>>> avoidable. For instance, if the code takes a spinlock, could it take an
> >>>> ERESOURCE instead.
> >>>>
> >>>>
> >>>> --
> >>>> Don Burn (MVP, Windows DDK)
> >>>> Windows 2k/XP/2k3 Filesystem and Driver Consulting
> >>>> http://www.windrvr.com
> >>>> Remove StopSpam from the email to reply
> >>>>
> >>>>
> >>>>
> >>>> <x856256(a)yahoo.com> wrote in message
> >>>> news:1154861486.219608.122660(a)m73g2000cwd.googlegroups.com...
> >>>>> Hello and thanks Don for the answer.
> >>>>>
> >>>>> It is running in IRQL_DISPATCH, I will try to reduce it and see what
> >>>>> happens.
> >>>>>
> >>>>> Thanks,
> >>>>> Guy
> >>>>>
> >>>>> Don Burn wrote:
> >>>>>> A filter hook driver should not have an interrupt handler it is only
> >>>>>> concerned with packets as they are presented to it. You should not
> >>>>>> try
> >>>>>> to
> >>>>>> use IoConnectInterrupt with a software interrupt.
> >>>>>>
> >>>>>> What IRQL are you running at when you crash, a common problem here
> >>>>>> would
> >>>>>> be
> >>>>>> calling the functions you mentioned at IRQL_DISPATCH or higher.
> >>>>>>
> >>>>>>
> >>>>>> --
> >>>>>> Don Burn (MVP, Windows DDK)
> >>>>>> Windows 2k/XP/2k3 Filesystem and Driver Consulting
> >>>>>> http://www.windrvr.com
> >>>>>> Remove StopSpam from the email to reply
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> <x856256(a)yahoo.com> wrote in message
> >>>>>> news:1154814887.364085.142850(a)n13g2000cwa.googlegroups.com...
> >>>>>>> Hi,
> >>>>>>>
> >>>>>>> Drivers are very new to me, can someone help me with the next issue
> >>>>>>> please:
> >>>>>>>
> >>>>>>> I have tried to set up a Filter Hook driver.
> >>>>>>> I took an example code from codeproject (DrvFltIp) and it works ok
> >>>>>>> on
> >>>>>>> my computer (Windows XP).
> >>>>>>>
> >>>>>>> When I try to process the packets more thoroughly than in this
> >>>>>>> example
> >>>>>>> code, my computer crashed (freezes or restarts immediately).
> >>>>>>> The crash happens when I do something that involves a
> >>>>>>> KeWaitForSingleObject or a KeDelayExecutionThread call (but I am not
> >>>>>>> sure these are the only scenarios that cause a crash).
> >>>>>>>
> >>>>>>> I looked in the dump file with WinDbg after the crash and saw that
> >>>>>>> one
> >>>>>>> of the last actions of the kernel were sending an interrupt and
> >>>>>>> afterwards an exception. So my guess was that the kernel is sending
> >>>>>>> a
> >>>>>>> trap that was sent to it by the hardware to my driver to handle, but
> >>>>>>> since I didn't set up an interrupt call back function, an exception
> >>>>>>> is
> >>>>>>> raised.
> >>>>>>> The next thing I did was to try and set up an interrupt call back
> >>>>>>> function, but this also caused a similar crash to the system (when I
> >>>>>>> tried to pull out the parameters that I have to pass to the function
> >>>>>>> "IoConnectInterrupt" from the isrStack). I tried to call the
> >>>>>>> function
> >>>>>>> "IoConnectInterrupt" from the function
> >>>>>>> "DriverObject->MajorFunction[IRP_MJ_CREATE]" when got
> >>>>>>> "IRP_MJ_CREATE"
> >>>>>>> in "irpStack->MajorFunction" or when I got "IRP_MN_START_DEVICE IRP"
> >>>>>>> in
> >>>>>>> "irpStack->MinorFunction". When I tried even to access the parameter
> >>>>>>> "irpStack->Parameters->StartDevice.AllocatedResourcesTranslated->Count"
> >>>>>>> (even without calling "IoConnectInterrupt") it caused a crash.
> >>>>>>>
> >>>>>>> If anyone can help me understand what I am doing wrong, and why I am
> >>>>>>> getting all these crashes I would be grateful.
> >>>>>>>
> >>>>>>> Thanks,
> >>>>>>> Guy
> >>>>>>>
> >

From: x856256 on 7 Aug 2006 01:37

From: soviet_bloke on 7 Aug 2006 02:15

Hi mate

It looks like guys have already told you that you cannot wait at IRQL
>= DISPATCH_LEVEL. It is understandable that you don't take "No" for an answer ( in your place I would not do it either), so that you are looking for some way around - after all,
no one explained to you why you cannot wait at IRQL >= DISPATCH_LEVEL.
Therefore, let me explain it to you in a very simple way, so that,
hopefully, you will stop thinking about trying to get around this
limitation

By calling any of Wait....() functions, your thread tells the system
that it does not want to run until something gets done by some other
thread (in your particular case, until packet gets processed). In order
for some other thread to start running, context switch is needed.
Context switch may occur only at IRQL < DISPATCH_LEVEL - as long as
IRQL is at or above DISPATCH_LEVEL, the system is not going to proceed
to the context switch.

In other words, logical chain stands as following:

Your thread does not want to run until "something" happens => this
"something" has to get done by some other thread => context switch is
required => IRQL must be below DISPATCH_LEVEL.

I hope by now you have already understood that waiting at IRQL >=
DISPATCH_LEVEL is among those things that just defeat the common sense,
so that a program that requires waiting at IRQL >= DISPATCH_LEVEL is
built upon some fundamental logical fallacy. Therefore, you have to
re-design your problem

Anton Bassov

x856256(a)yahoo.com wrote:
> Hello,
>
> Either queueing the job or doing it asynchronously I will have to do
> the job in another thread, and wait for the process of the packet to
> finish (in order to return the drop, forward or pass reply), and this
> is exactly where my problem began, when I tried to use the
> KeWaitForSingleObject function.
> So let me ask this again: How can I use this wait function, or any
> other substitution that will allow me process the packet on another
> thread (queued or not) and wait for it to finish processing in order to
> return the value?
>
> Thanks,
> Guy
>
> Doron Holan [MS] wrote:
> > you can't reduce IRQL inline, you can only raise it and then lower it. if
> > you truly want to synchronously process soemthing, then queue it to a work
> > item. if you want your filter to not negatively affect performance, learn
> > how to process the results in the completion routine asynchronously
> >
> > d
> >
> > --
> > Please do not send e-mail directly to this alias. this alias is for
> > newsgroup purposes only.
> > This posting is provided "AS IS" with no warranties, and confers no rights.
> >
> >
> > <x856256(a)yahoo.com> wrote in message
> > news:1154873993.596484.241370(a)i42g2000cwa.googlegroups.com...
> > > No,
> > >
> > > The code is not taking any spinlocks.
> > > Anyone has an idea how can I reduce the IRQL level inside the filter
> > > hook function?
> > >
> > > Thanks,
> > > Guy
> > >
> > > Don Burn wrote:
> > >> You cannot call a lot of functions at DISPATCH_LEVEL. I am not well
> > >> versed
> > >> in filter hooks, so you need to determine if the raising to DISPATCH is
> > >> avoidable. For instance, if the code takes a spinlock, could it take an
> > >> ERESOURCE instead.
> > >>
> > >>
> > >> --
> > >> Don Burn (MVP, Windows DDK)
> > >> Windows 2k/XP/2k3 Filesystem and Driver Consulting
> > >> http://www.windrvr.com
> > >> Remove StopSpam from the email to reply
> > >>
> > >>
> > >>
> > >> <x856256(a)yahoo.com> wrote in message
> > >> news:1154861486.219608.122660(a)m73g2000cwd.googlegroups.com...
> > >> > Hello and thanks Don for the answer.
> > >> >
> > >> > It is running in IRQL_DISPATCH, I will try to reduce it and see what
> > >> > happens.
> > >> >
> > >> > Thanks,
> > >> > Guy
> > >> >
> > >> > Don Burn wrote:
> > >> >> A filter hook driver should not have an interrupt handler it is only
> > >> >> concerned with packets as they are presented to it. You should not
> > >> >> try
> > >> >> to
> > >> >> use IoConnectInterrupt with a software interrupt.
> > >> >>
> > >> >> What IRQL are you running at when you crash, a common problem here
> > >> >> would
> > >> >> be
> > >> >> calling the functions you mentioned at IRQL_DISPATCH or higher.
> > >> >>
> > >> >>
> > >> >> --
> > >> >> Don Burn (MVP, Windows DDK)
> > >> >> Windows 2k/XP/2k3 Filesystem and Driver Consulting
> > >> >> http://www.windrvr.com
> > >> >> Remove StopSpam from the email to reply
> > >> >>
> > >> >>
> > >> >>
> > >> >> <x856256(a)yahoo.com> wrote in message
> > >> >> news:1154814887.364085.142850(a)n13g2000cwa.googlegroups.com...
> > >> >> > Hi,
> > >> >> >
> > >> >> > Drivers are very new to me, can someone help me with the next issue
> > >> >> > please:
> > >> >> >
> > >> >> > I have tried to set up a Filter Hook driver.
> > >> >> > I took an example code from codeproject (DrvFltIp) and it works ok
> > >> >> > on
> > >> >> > my computer (Windows XP).
> > >> >> >
> > >> >> > When I try to process the packets more thoroughly than in this
> > >> >> > example
> > >> >> > code, my computer crashed (freezes or restarts immediately).
> > >> >> > The crash happens when I do something that involves a
> > >> >> > KeWaitForSingleObject or a KeDelayExecutionThread call (but I am not
> > >> >> > sure these are the only scenarios that cause a crash).
> > >> >> >
> > >> >> > I looked in the dump file with WinDbg after the crash and saw that
> > >> >> > one
> > >> >> > of the last actions of the kernel were sending an interrupt and
> > >> >> > afterwards an exception. So my guess was that the kernel is sending
> > >> >> > a
> > >> >> > trap that was sent to it by the hardware to my driver to handle, but
> > >> >> > since I didn't set up an interrupt call back function, an exception
> > >> >> > is
> > >> >> > raised.
> > >> >> > The next thing I did was to try and set up an interrupt call back
> > >> >> > function, but this also caused a similar crash to the system (when I
> > >> >> > tried to pull out the parameters that I have to pass to the function
> > >> >> > "IoConnectInterrupt" from the isrStack). I tried to call the
> > >> >> > function
> > >> >> > "IoConnectInterrupt" from the function
> > >> >> > "DriverObject->MajorFunction[IRP_MJ_CREATE]" when got
> > >> >> > "IRP_MJ_CREATE"
> > >> >> > in "irpStack->MajorFunction" or when I got "IRP_MN_START_DEVICE IRP"
> > >> >> > in

From: x856256 on 7 Aug 2006 04:02

Hi there folks,

I didn't mean to be stubborn.

Thank you all for helping me.

Guy

soviet_bloke(a)hotmail.com wrote:
> Hi mate
>
> It looks like guys have already told you that you cannot wait at IRQL
> >= DISPATCH_LEVEL. It is understandable that you don't take "No" for an answer ( in your place I would not do it either), so that you are looking for some way around - after all,
> no one explained to you why you cannot wait at IRQL >= DISPATCH_LEVEL.
> Therefore, let me explain it to you in a very simple way, so that,
> hopefully, you will stop thinking about trying to get around this
> limitation
>
>
> By calling any of Wait....() functions, your thread tells the system
> that it does not want to run until something gets done by some other
> thread (in your particular case, until packet gets processed). In order
> for some other thread to start running, context switch is needed.
> Context switch may occur only at IRQL < DISPATCH_LEVEL - as long as
> IRQL is at or above DISPATCH_LEVEL, the system is not going to proceed
> to the context switch.
>
>
> In other words, logical chain stands as following:
>
>
> Your thread does not want to run until "something" happens => this
> "something" has to get done by some other thread => context switch is
> required => IRQL must be below DISPATCH_LEVEL.
>
>
> I hope by now you have already understood that waiting at IRQL >=
> DISPATCH_LEVEL is among those things that just defeat the common sense,
> so that a program that requires waiting at IRQL >= DISPATCH_LEVEL is
> built upon some fundamental logical fallacy. Therefore, you have to
> re-design your problem
>
> Anton Bassov
>
>
>
>
> x856256(a)yahoo.com wrote:
> > Hello,
> >
> > Either queueing the job or doing it asynchronously I will have to do
> > the job in another thread, and wait for the process of the packet to
> > finish (in order to return the drop, forward or pass reply), and this
> > is exactly where my problem began, when I tried to use the
> > KeWaitForSingleObject function.
> > So let me ask this again: How can I use this wait function, or any
> > other substitution that will allow me process the packet on another
> > thread (queued or not) and wait for it to finish processing in order to
> > return the value?
> >
> > Thanks,
> > Guy
> >
> > Doron Holan [MS] wrote:
> > > you can't reduce IRQL inline, you can only raise it and then lower it. if
> > > you truly want to synchronously process soemthing, then queue it to a work
> > > item. if you want your filter to not negatively affect performance, learn
> > > how to process the results in the completion routine asynchronously
> > >
> > > d
> > >
> > > --
> > > Please do not send e-mail directly to this alias. this alias is for
> > > newsgroup purposes only.
> > > This posting is provided "AS IS" with no warranties, and confers no rights.
> > >
> > >
> > > <x856256(a)yahoo.com> wrote in message
> > > news:1154873993.596484.241370(a)i42g2000cwa.googlegroups.com...
> > > > No,
> > > >
> > > > The code is not taking any spinlocks.
> > > > Anyone has an idea how can I reduce the IRQL level inside the filter
> > > > hook function?
> > > >
> > > > Thanks,
> > > > Guy
> > > >
> > > > Don Burn wrote:
> > > >> You cannot call a lot of functions at DISPATCH_LEVEL. I am not well
> > > >> versed
> > > >> in filter hooks, so you need to determine if the raising to DISPATCH is
> > > >> avoidable. For instance, if the code takes a spinlock, could it take an
> > > >> ERESOURCE instead.
> > > >>
> > > >>
> > > >> --
> > > >> Don Burn (MVP, Windows DDK)
> > > >> Windows 2k/XP/2k3 Filesystem and Driver Consulting
> > > >> http://www.windrvr.com
> > > >> Remove StopSpam from the email to reply
> > > >>
> > > >>
> > > >>
> > > >> <x856256(a)yahoo.com> wrote in message
> > > >> news:1154861486.219608.122660(a)m73g2000cwd.googlegroups.com...
> > > >> > Hello and thanks Don for the answer.
> > > >> >
> > > >> > It is running in IRQL_DISPATCH, I will try to reduce it and see what
> > > >> > happens.
> > > >> >
> > > >> > Thanks,
> > > >> > Guy
> > > >> >
> > > >> > Don Burn wrote:
> > > >> >> A filter hook driver should not have an interrupt handler it is only
> > > >> >> concerned with packets as they are presented to it. You should not
> > > >> >> try
> > > >> >> to
> > > >> >> use IoConnectInterrupt with a software interrupt.
> > > >> >>
> > > >> >> What IRQL are you running at when you crash, a common problem here
> > > >> >> would
> > > >> >> be
> > > >> >> calling the functions you mentioned at IRQL_DISPATCH or higher.
> > > >> >>
> > > >> >>
> > > >> >> --
> > > >> >> Don Burn (MVP, Windows DDK)
> > > >> >> Windows 2k/XP/2k3 Filesystem and Driver Consulting
> > > >> >> http://www.windrvr.com
> > > >> >> Remove StopSpam from the email to reply
> > > >> >>
> > > >> >>
> > > >> >>
> > > >> >> <x856256(a)yahoo.com> wrote in message
> > > >> >> news:1154814887.364085.142850(a)n13g2000cwa.googlegroups.com...
> > > >> >> > Hi,
> > > >> >> >
> > > >> >> > Drivers are very new to me, can someone help me with the next issue
> > > >> >> > please:
> > > >> >> >
> > > >> >> > I have tried to set up a Filter Hook driver.
> > > >> >> > I took an example code from codeproject (DrvFltIp) and it works ok
> > > >> >> > on
> > > >> >> > my computer (Windows XP).
> > > >> >> >
> > > >> >> > When I try to process the packets more thoroughly than in this
> > > >> >> > example
> > > >> >> > code, my computer crashed (freezes or restarts immediately).
> > > >> >> > The crash happens when I do something that involves a
> > > >> >> > KeWaitForSingleObject or a KeDelayExecutionThread call (but I am not
> > > >> >> > sure these are the only scenarios that cause a crash).
> > > >> >> >
> > > >> >> > I looked in the dump file with WinDbg after the crash and saw that
> > > >> >> > one
> > > >> >> > of the last actions of the kernel were sending an interrupt and
> > > >> >> > afterwards an exception. So my guess was that the kernel is sending
> > > >> >> > a
> > > >> >> > trap that was sent to it by the hardware to my driver to handle, but
> > > >> >> > since I didn't set up an interrupt call back function, an exception
> > > >> >> > is
> > > >> >> > raised.
> > > >> >> > The next thing I did was to try and set up an interrupt call back
> > > >> >> > function, but this also caused a similar crash to the system (when I

First | Prev | Next | Last
Pages: 1 2 3 4 5
Prev: PacketStackSize
Next: Loading winusb.sys in Window XP