Hi everyone
Does anyone know conditions when exception handling fails? I’ve encountered
that fault within a __try/__except block in a driver in W2K Server causes
blue screen. Is there any way to regulate this NTOSKRNL behaviour?
Thanx.
Hi everyone
Does anyone know conditions when exception handling fails? I’ve encountered
that fault within a __try/__except block in a driver in W2K Server causes
blue screen. Is there any way to regulate this NTOSKRNL behaviour?
Thanx.
SEH does not prevent blue screens: it can catch simple programming
errors (i.e. referencing a NULL pointer in your routine, stuff like that),
but there are many runtime circumstances that will cause a bugcheck despite
the presence of SEH. Many times user mode developers writing kernel code
assume SEH will prevent the system from crashing, much as SEH kept their
user mode processes from crashing (I made this assumption in the beginning)
-----Original Message-----
From: xxxxx@storactive.com
[mailto:xxxxx@storactive.com]
Sent: Tuesday, September 05, 2000 2:24 AM
To: NT Developers Interest List
Subject: [ntdev] Exceptions handling in W2K Server
Hi everyone
Does anyone know conditions when exception handling fails? I’ve encountered
that fault within a __try/__except block in a driver in W2K Server causes
blue screen. Is there any way to regulate this NTOSKRNL behaviour?
Thanx.
You are currently subscribed to ntdev as: xxxxx@ntpsoftware.com
To unsubscribe send a blank email to $subst(‘Email.Unsub’)
Thank you for the answer Joel
I really thought MS VC++ SEH extension (__try/__except blocks) DO prevent
kernel code from the blue screen appearance. And my past experience proved
that (faults within such blocks were caught, no BS and exception handler
was called). That was true for NT 4.0 and W2K Professional. But things go
different in W2K Server. So I’m wondering what is the difference between
those platforms?
On 09/05/00, ““Smith, Joel” ” wrote:
> This message is in MIME format. Since your mail reader does not understand
> this format, some or all of this message may not be legible.
>
> ------_=NextPart_001_01C01740.4DB5A6B0
> Content-Type: text/plain;
> charset=“iso-8859-1”
>
> SEH does not prevent blue screens: it can catch simple programming
> errors (i.e. referencing a NULL pointer in your routine, stuff like that),
> but there are many runtime circumstances that will cause a bugcheck despite
> the presence of SEH. Many times user mode developers writing kernel code
> assume SEH will prevent the system from crashing, much as SEH kept their
> user mode processes from crashing (I made this assumption in the beginning)
> - but this isn’t the case.
> If you’re getting a panic inside an exception handling block, the
> most likely cause is trying to access paged memory while at IRQL >=
> DISPATCH_LEVEL. If you’re seeing an IRQL_NOT_LESS_OR_EQUAL bug code in
> you’re crash, you’ve most likely got a wild pointer somewhere and are trying
> to pass it to some kernel routine. Typical examples are trying to free an
> invalid pointer, trying to wait on a synch object which has already been
> freed, is not properly initialized, etc. These are easy to diagnose with a
> simple stack trace when debugging.
>
>
> -----Original Message-----
> From: xxxxx@storactive.com
> [mailto:xxxxx@storactive.com]
> Sent: Tuesday, September 05, 2000 2:24 AM
> To: NT Developers Interest List
> Subject: [ntdev] Exceptions handling in W2K Server
>
>
> Hi everyone
> Does anyone know conditions when exception handling fails? I’ve encountered
> that fault within a try/ except block in a driver in W2K Server causes
> blue screen. Is there any way to regulate this NTOSKRNL behaviour?
>
> Thanx.
>
>
> —
> You are currently subscribed to ntdev as: xxxxx@ntpsoftware.com
> To unsubscribe send a blank email to $subst(‘Email.Unsub’)
>
> ------=NextPart_001_01C01740.4DB5A6B0
> Content-Type: text/html;
> charset=“iso-8859-1”
> Content-Transfer-Encoding: quoted-printable
>
>
>
>
> > charset=3Diso-8859-1">
> > 5.5.2650.12">
> RE: [ntdev] Exceptions handling in W2K Server
>
>
>
>
SEH does =
> not prevent blue screens: it can catch simple programming errors =
> (i.e. referencing a NULL pointer in your routine, stuff like that), but =
> there are many runtime circumstances that will cause a bugcheck despite =
> the presence of SEH. Many times user mode developers writing =
> kernel code assume SEH will prevent the system from crashing, much as =
> SEH kept their user mode processes from crashing (I made this =
> assumption in the beginning) - but this isn’t the case.
If you’re =
> getting a panic inside an exception handling block, the most likely =
> cause is trying to access paged memory while at IRQL >=3D =
> DISPATCH_LEVEL. If you’re seeing an IRQL_NOT_LESS_OR_EQUAL bug =
> code in you’re crash, you’ve most likely got a wild pointer somewhere =
> and are trying to pass it to some kernel routine. Typical =
> examples are trying to free an invalid pointer, trying to wait on a =
> synch object which has already been freed, is not properly initialized, =
> etc. These are easy to diagnose with a simple stack trace when =
> debugging.
>
-----Original Message-----
>
From: xxxxx@storactive.com
>
[> HREF=3D"mailto:xxxxx@storactive.com">mailto:Alexey_Malinniko=
> xxxxx@storactive.com]
>
Sent: Tuesday, September 05, 2000 2:24 AM
>
To: NT Developers Interest List
>
Subject: [ntdev] Exceptions handling in W2K =
> Server
>
Hi everyone
>
Does anyone know conditions when exception handling =
> fails? I’ve encountered
>
that fault within a try/ except block in a driver =
> in W2K Server causes
>
blue screen. Is there any way to regulate this =
> NTOSKRNL behaviour?
>
Thanx.
>
>
—
>
You are currently subscribed to ntdev as: =
> xxxxx@ntpsoftware.com
>
To unsubscribe send a blank email to =
> $subst(‘Email.Unsub’)
>
It isn’t clear what you mean by ‘faults’. It also isn’t clear exactly what
crash you are experiencing. Perhaps if you provided a little bit more
information we could end the speculation.
On the other hand, the kernel is the same for both W2K professional and W2K
server. There are features that can be enabled in W2K Server, but offhand,
and without any real information about your problem, it really is unlikely
that some feature of W2K Server is disabling whatever protection it is you
thought you were obtaining through the use of SEH.
Also, the damage that may have proceeded the actual exception is not
magically undone by having an exception handler. SEH is not a panacea for
bad code.
Mark Roddy
Windows 2000/NT Consultant
Hollis Technology Solutions
www.hollistech.com
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of
xxxxx@storactive.com
Sent: Tuesday, September 05, 2000 10:00 AM
To: NT Developers Interest List
Subject: [ntdev] RE: Exceptions handling in W2K ServerThank you for the answer Joel
I really thought MS VC++ SEH extension (__try/__except blocks) DO prevent
kernel code from the blue screen appearance. And my past
experience proved
that (faults within such blocks were caught, no BS and exception handler
was called). That was true for NT 4.0 and W2K Professional. But things go
different in W2K Server. So I’m wondering what is the difference between
those platforms?On 09/05/00, ““Smith, Joel” ” wrote:
> > This message is in MIME format. Since your mail reader does not
> understand
> > this format, some or all of this message may not be legible.
> >
> > ------_=NextPart_001_01C01740.4DB5A6B0
> > Content-Type: text/plain;
> > charset=“iso-8859-1”
> >
> > SEH does not prevent blue screens: it can catch simple programming
> > errors (i.e. referencing a NULL pointer in your routine, stuff
> like that),
> > but there are many runtime circumstances that will cause a
> bugcheck despite
> > the presence of SEH. Many times user mode developers writing
> kernel code
> > assume SEH will prevent the system from crashing, much as SEH kept their
> > user mode processes from crashing (I made this assumption in
> the beginning)
> > - but this isn’t the case.
> > If you’re getting a panic inside an exception handling block, the
> > most likely cause is trying to access paged memory while at IRQL >=
> > DISPATCH_LEVEL. If you’re seeing an IRQL_NOT_LESS_OR_EQUAL bug code in
> > you’re crash, you’ve most likely got a wild pointer somewhere
> and are trying
> > to pass it to some kernel routine. Typical examples are trying
> to free an
> > invalid pointer, trying to wait on a synch object which has already been
> > freed, is not properly initialized, etc. These are easy to
> diagnose with a
> > simple stack trace when debugging.
> >
> >
> > -----Original Message-----
> > From: xxxxx@storactive.com
> > [mailto:xxxxx@storactive.com]
> > Sent: Tuesday, September 05, 2000 2:24 AM
> > To: NT Developers Interest List
> > Subject: [ntdev] Exceptions handling in W2K Server
> >
> >
> > Hi everyone
> > Does anyone know conditions when exception handling fails? I’ve
> encountered
> > that fault within a try/ except block in a driver in W2K
> Server causes
> > blue screen. Is there any way to regulate this NTOSKRNL behaviour?
> >
> > Thanx.
> >
> >
> > —
> > You are currently subscribed to ntdev as: xxxxx@ntpsoftware.com
> > To unsubscribe send a blank email to $subst(‘Email.Unsub’)
> >
> > ------=NextPart_001_01C01740.4DB5A6B0
> > Content-Type: text/html;
> > charset=“iso-8859-1”
> > Content-Transfer-Encoding: quoted-printable
> >
> >
> >
> >
> > > > charset=3Diso-8859-1">
> > > > 5.5.2650.12">
> > RE: [ntdev] Exceptions handling in W2K Server
> >
> >
> >
> >SEH does =
> > not prevent blue screens: it can catch simple programming errors =
> > (i.e. referencing a NULL pointer in your routine, stuff like
> that), but =
> > there are many runtime circumstances that will cause a bugcheck
> despite =
> > the presence of SEH. Many times user mode developers writing =
> > kernel code assume SEH will prevent the system from crashing, much as =
> > SEH kept their user mode processes from crashing (I made this =
> > assumption in the beginning) - but this isn’t the case.
> >
> >If you’re =
> > getting a panic inside an exception handling block, the most likely =
> > cause is trying to access paged memory while at IRQL >=3D =
> > DISPATCH_LEVEL. If you’re seeing an IRQL_NOT_LESS_OR_EQUAL bug =
> > code in you’re crash, you’ve most likely got a wild pointer somewhere =
> > and are trying to pass it to some kernel routine. Typical =
> > examples are trying to free an invalid pointer, trying to wait on a =
> > synch object which has already been freed, is not properly
> initialized, =
> > etc. These are easy to diagnose with a simple stack trace when =
> > debugging.
> >
> >
> >
> >
> >-----Original Message-----
> >
From: xxxxx@storactive.com
> >
[> >
> HREF=3D"mailto:xxxxx@storactive.com">mailto:Alexey_Malinniko=
> > xxxxx@storactive.com]
> >
Sent: Tuesday, September 05, 2000 2:24 AM
> >
To: NT Developers Interest List
> >
Subject: [ntdev] Exceptions handling in W2K =
> > Server
> >
> >
> >
> >Hi everyone
> >
Does anyone know conditions when exception handling =
> > fails? I’ve encountered
> >
that fault within a try/ except block in
> a driver =
> > in W2K Server causes
> >
blue screen. Is there any way to regulate this =
> > NTOSKRNL behaviour?
> >
> >
> >Thanx.
> >
> >
> >
> >—
> >
You are currently subscribed to ntdev as: =
> > xxxxx@ntpsoftware.com
> >
To unsubscribe send a blank email to =
> > $subst(‘Email.Unsub’)
> >
> >
> >
> >
> > ------=_NextPart_001_01C01740.4DB5A6B0–
>
> —
> You are currently subscribed to ntdev as: xxxxx@wattanuck.mv.com
> To unsubscribe send a blank email to $subst(‘Email.Unsub’)
>
>
By “faults” I mean fatal errors causing NT/2K to stop execution and show
blue screen. In my case I have some variations of them (FAT_FILE_SYSTEM
bugcheck and
KMODE_EXCEPTION_NOT_HANDLED with 0x80000003 [embedded int 3] code) but all
of them are caused by incorrect file open type in FsContext. However, this
incorrect IRP IS NOT generated by my FS filter but by IOStress test.
Besides, W2K Professional and W2K Server DO NOT have BINARY the same
NTOSKRNL (just try to run fc /b, for example).
I know using SEH is not a good way to prevent faults but I see no other way
to handle this.
On 09/05/00, ““Mark Roddy” ” wrote:
> It isn’t clear what you mean by ‘faults’. It also isn’t clear exactly what
> crash you are experiencing. Perhaps if you provided a little bit more
> information we could end the speculation.
>
> On the other hand, the kernel is the same for both W2K professional and W2K
> server. There are features that can be enabled in W2K Server, but offhand,
> and without any real information about your problem, it really is unlikely
> that some feature of W2K Server is disabling whatever protection it is you
> thought you were obtaining through the use of SEH.
>
> Also, the damage that may have proceeded the actual exception is not
> magically undone by having an exception handler. SEH is not a panacea for
> bad code.
>
>
>
> Mark Roddy
> Windows 2000/NT Consultant
> Hollis Technology Solutions
> www.hollistech.com
>
> > -----Original Message-----
> > From: xxxxx@lists.osr.com
> > [mailto:xxxxx@lists.osr.com]On Behalf Of
> > xxxxx@storactive.com
> > Sent: Tuesday, September 05, 2000 10:00 AM
> > To: NT Developers Interest List
> > Subject: [ntdev] RE: Exceptions handling in W2K Server
> >
> >
> > Thank you for the answer Joel
> >
> > I really thought MS VC++ SEH extension ( try/ except blocks) DO prevent
> > kernel code from the blue screen appearance. And my past
> > experience proved
> > that (faults within such blocks were caught, no BS and exception handler
> > was called). That was true for NT 4.0 and W2K Professional. But things go
> > different in W2K Server. So I’m wondering what is the difference between
> > those platforms?
> >
> > On 09/05/00, ““Smith, Joel” ” wrote:
> > > This message is in MIME format. Since your mail reader does not
> > understand
> > > this format, some or all of this message may not be legible.
> > >
> > > ------_=NextPart_001_01C01740.4DB5A6B0
> > > Content-Type: text/plain;
> > > charset=“iso-8859-1”
> > >
> > > SEH does not prevent blue screens: it can catch simple programming
> > > errors (i.e. referencing a NULL pointer in your routine, stuff
> > like that),
> > > but there are many runtime circumstances that will cause a
> > bugcheck despite
> > > the presence of SEH. Many times user mode developers writing
> > kernel code
> > > assume SEH will prevent the system from crashing, much as SEH kept their
> > > user mode processes from crashing (I made this assumption in
> > the beginning)
> > > - but this isn’t the case.
> > > If you’re getting a panic inside an exception handling block, the
> > > most likely cause is trying to access paged memory while at IRQL >=
> > > DISPATCH_LEVEL. If you’re seeing an IRQL_NOT_LESS_OR_EQUAL bug code in
> > > you’re crash, you’ve most likely got a wild pointer somewhere
> > and are trying
> > > to pass it to some kernel routine. Typical examples are trying
> > to free an
> > > invalid pointer, trying to wait on a synch object which has already been
> > > freed, is not properly initialized, etc. These are easy to
> > diagnose with a
> > > simple stack trace when debugging.
> > >
> > >
> > > -----Original Message-----
> > > From: xxxxx@storactive.com
> > > [mailto:xxxxx@storactive.com]
> > > Sent: Tuesday, September 05, 2000 2:24 AM
> > > To: NT Developers Interest List
> > > Subject: [ntdev] Exceptions handling in W2K Server
> > >
> > >
> > > Hi everyone
> > > Does anyone know conditions when exception handling fails? I’ve
> > encountered
> > > that fault within a try/ except block in a driver in W2K
> > Server causes
> > > blue screen. Is there any way to regulate this NTOSKRNL behaviour?
> > >
> > > Thanx.
> > >
> > >
> > > —
> > > You are currently subscribed to ntdev as: xxxxx@ntpsoftware.com
> > > To unsubscribe send a blank email to $subst(‘Email.Unsub’)
> > >
> > > ------=NextPart_001_01C01740.4DB5A6B0
> > > Content-Type: text/html;
> > > charset=“iso-8859-1”
> > > Content-Transfer-Encoding: quoted-printable
> > >
> > >
> > >
> > >
> > > > > > charset=3Diso-8859-1">
> > > > > > 5.5.2650.12">
> > > RE: [ntdev] Exceptions handling in W2K Server
> > >
> > >
> > >
> > >
SEH does =
> > > not prevent blue screens: it can catch simple programming errors =
> > > (i.e. referencing a NULL pointer in your routine, stuff like
> > that), but =
> > > there are many runtime circumstances that will cause a bugcheck
> > despite =
> > > the presence of SEH. Many times user mode developers writing =
> > > kernel code assume SEH will prevent the system from crashing, much as =
> > > SEH kept their user mode processes from crashing (I made this =
> > > assumption in the beginning) - but this isn’t the case.
If you’re =
> > > getting a panic inside an exception handling block, the most likely =
> > > cause is trying to access paged memory while at IRQL >=3D =
> > > DISPATCH_LEVEL. If you’re seeing an IRQL_NOT_LESS_OR_EQUAL bug =
> > > code in you’re crash, you’ve most likely got a wild pointer somewhere =
> > > and are trying to pass it to some kernel routine. Typical =
> > > examples are trying to free an invalid pointer, trying to wait on a =
> > > synch object which has already been freed, is not properly
> > initialized, =
> > > etc. These are easy to diagnose with a simple stack trace when =
> > > debugging.
> > >
-----Original Message-----
> > >
From: xxxxx@storactive.com
> > >
[> > >
> > HREF=3D"mailto:xxxxx@storactive.com">mailto:Alexey_Malinniko=
> > > xxxxx@storactive.com]
> > >
Sent: Tuesday, September 05, 2000 2:24 AM
> > >
To: NT Developers Interest List
> > >
Subject: [ntdev] Exceptions handling in W2K =
> > > Server
> > >
Hi everyone
> > >
Does anyone know conditions when exception handling =
> > > fails? I’ve encountered
> > >
that fault within a try/ except block in
> > a driver =
> > > in W2K Server causes
> > >
blue screen. Is there any way to regulate this =
> > > NTOSKRNL behaviour?
> > >
Thanx.
> > >
> > >
—
> > >
You are currently subscribed to ntdev as: =
> > > xxxxx@ntpsoftware.com
> > >
To unsubscribe send a blank email to =
> > > $subst(‘Email.Unsub’)
> > >
> -----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of
xxxxx@storactive.com
Sent: Wednesday, September 06, 2000 5:50 AM
To: NT Developers Interest List
Subject: [ntdev] RE: Exceptions handling in W2K ServerBy “faults” I mean fatal errors causing NT/2K to stop execution and show
blue screen. In my case I have some variations of them (FAT_FILE_SYSTEM
bugcheck and
KMODE_EXCEPTION_NOT_HANDLED with 0x80000003 [embedded int 3]
code) but all
of them are caused by incorrect file open type in FsContext.
However, this
incorrect IRP IS NOT generated by my FS filter but by IOStress test.
A bugcheck is not going to be handled by your SEH as it is going to route to
the bugcheck functions.
The general rule is that if a crash happens with your filter installed and
doesn’t happen with your filter not installed, then your filter is the cause
of the crash, regardless of where the IRP was generated, or how bad the code
is above or below you.
Besides, W2K Professional and W2K Server DO NOT have BINARY the same
NTOSKRNL (just try to run fc /b, for example).I know using SEH is not a good way to prevent faults but I see no
other way
to handle this.
You cannot handle bugchecks via SEH. You need to find the cause of the
problem. The IFS kit comes with a version of the FAT filesystem that might
help you track down what is causing the bugcheck.
> I really thought MS VC++ SEH extension (__try/__except blocks) DO prevent
kernel code from the blue screen appearance. And my past experience proved
that (faults within such blocks were caught, no BS and exception handler
was called). That was true for NT 4.0 and W2K Professional. But things go
different in W2K Server. So I’m wondering what is the difference between
those platforms?
SEH will not catch bugchecks like IRQL_NOT_LESS_OR_EQUAL or
PAGE_FAULT_IN_NONPAGED_AREA.
SEH catches only ExRaiseStatus, not KeBugCheckEx.
Max