Hi all,
I call ObReference…() as follows:
status=ObReferenceObjectByHandle(Handle,0,*IoFileObjectType,KernelMode,&Obje
ct,NULL);
On Success this is followed by a call to RtlVolume…() which is:
status = RtlVolumeDeviceToDosName((PVOID)(((FILE_OBJECT
*)Object)->DeviceObject),Parent);
This code sometimes causes my driver to crash with a double fault
UNEXPECTED_KERNEL_MODE_TRAP (7f) 8 = double fault,
WinDbg shows the FollowupIP as RtlpSetSecurityObject+74.
MSDN documentation states that failure to validate object handles may result
in non-reliable driver performance. Could this be the reason for the crash.
If so, then what steps could be taken to verify the validity of objects. I
want to consider only FileObject of FileSystems. In any case, don’t the
KPI’s themselves return an appropriate error code in case of a fault.
I’m quite stuck,
Thanks
Samarth
Double faults are generally due to stack overflows. Get a stack trace to
debug further.
-----Original Message-----
From: Samarth Sharma [mailto:xxxxx@mynetsec.com]
Sent: Wednesday, July 30, 2003 3:18 AM
To: Windows System Software Developers Interest List
Subject: [ntdev] Double Fault
Hi all,
I call ObReference…() as follows:
status=ObReferenceObjectByHandle(Handle,0,*IoFileObjectType,KernelMode,&Obje
ct,NULL);
On Success this is followed by a call to RtlVolume…() which is:
status = RtlVolumeDeviceToDosName((PVOID)(((FILE_OBJECT
*)Object)->DeviceObject),Parent);
This code sometimes causes my driver to crash with a double fault
UNEXPECTED_KERNEL_MODE_TRAP (7f) 8 = double fault,
WinDbg shows the FollowupIP as RtlpSetSecurityObject+74.
MSDN documentation states that failure to validate object handles may result
in non-reliable driver performance. Could this be the reason for the crash.
If so, then what steps could be taken to verify the validity of objects. I
want to consider only FileObject of FileSystems. In any case, don’t the
KPI’s themselves return an appropriate error code in case of a fault.
I’m quite stuck,
Thanks
Samarth
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
You are currently subscribed to ntdev as: xxxxx@stratus.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
Hi,
Another thing, there is a DbgPrint() statement as the control is about to
leave the function. If i remove this DbgPrint() statement then the BSOD does
not occur.
The stack trace of the crash shows RtlpSetSecurityObject+74 as the last
call.
The handle to ObRef…() is not validated and neither is the Object pointer
to RtlVolumeDevicetoDosName()…
Any ideas what could be going wrong??
Thanks,
Samarth
“Croci, MaryBeth” wrote in message
news:xxxxx@ntdev…
>
> Double faults are generally due to stack overflows. Get a stack trace to
> debug further.
>
> -----Original Message-----
> From: Samarth Sharma [mailto:xxxxx@mynetsec.com]
> Sent: Wednesday, July 30, 2003 3:18 AM
> To: Windows System Software Developers Interest List
> Subject: [ntdev] Double Fault
>
>
> Hi all,
> I call ObReference…() as follows:
>
>
status=ObReferenceObjectByHandle(Handle,0,*IoFileObjectType,KernelMode,&Obje
> ct,NULL);
>
> On Success this is followed by a call to RtlVolume…() which is:
> status = RtlVolumeDeviceToDosName((PVOID)(((FILE_OBJECT
> *)Object)->DeviceObject),Parent);
>
> This code sometimes causes my driver to crash with a double fault
> UNEXPECTED_KERNEL_MODE_TRAP (7f) 8 = double fault,
>
> WinDbg shows the FollowupIP as RtlpSetSecurityObject+74.
> MSDN documentation states that failure to validate object handles may
result
> in non-reliable driver performance. Could this be the reason for the
crash.
> If so, then what steps could be taken to verify the validity of objects. I
> want to consider only FileObject of FileSystems. In any case, don’t the
> KPI’s themselves return an appropriate error code in case of a fault.
>
> I’m quite stuck,
> Thanks
> Samarth
>
>
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: xxxxx@stratus.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
>
>
Two things:
* With double fault, I generally look for recursion or a huge frame
somewhere, so the last call on the stack trace isn’t enough. You need to
look at the entire trace.
* If removing a DbgPrint cures the problem, there might be something wrong
with the statement.
-----Original Message-----
From: Samarth Sharma [mailto:xxxxx@mynetsec.com]
Sent: Thursday, July 31, 2003 9:01 AM
To: Windows System Software Developers Interest List
Subject: [ntdev] Re: Double Fault
Hi,
Another thing, there is a DbgPrint() statement as the control is about to
leave the function. If i remove this DbgPrint() statement then the BSOD does
not occur.
The stack trace of the crash shows RtlpSetSecurityObject+74 as the last
call.
The handle to ObRef…() is not validated and neither is the Object pointer
to RtlVolumeDevicetoDosName()…
Any ideas what could be going wrong??
Thanks,
Samarth
“Croci, MaryBeth” wrote in message
news:xxxxx@ntdev…
>
> Double faults are generally due to stack overflows. Get a stack trace to
> debug further.
>
> -----Original Message-----
> From: Samarth Sharma [mailto:xxxxx@mynetsec.com]
> Sent: Wednesday, July 30, 2003 3:18 AM
> To: Windows System Software Developers Interest List
> Subject: [ntdev] Double Fault
>
>
> Hi all,
> I call ObReference…() as follows:
>
>
status=ObReferenceObjectByHandle(Handle,0,*IoFileObjectType,KernelMode,&Obje
> ct,NULL);
>
> On Success this is followed by a call to RtlVolume…() which is:
> status = RtlVolumeDeviceToDosName((PVOID)(((FILE_OBJECT
> *)Object)->DeviceObject),Parent);
>
> This code sometimes causes my driver to crash with a double fault
> UNEXPECTED_KERNEL_MODE_TRAP (7f) 8 = double fault,
>
> WinDbg shows the FollowupIP as RtlpSetSecurityObject+74.
> MSDN documentation states that failure to validate object handles may
result
> in non-reliable driver performance. Could this be the reason for the
crash.
> If so, then what steps could be taken to verify the validity of objects. I
> want to consider only FileObject of FileSystems. In any case, don’t the
> KPI’s themselves return an appropriate error code in case of a fault.
>
> I’m quite stuck,
> Thanks
> Samarth
>
>
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: xxxxx@stratus.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@stratus.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
Hi,
Well i was using recursion in the function, but today i replaced that part
with a non-recursive one implementation. However,
the problem still persists.
The DbgPrint statement is: DbgPrint(“Deallocating buffer”); so there cannot
really be anything wrong with the DbgPrint().
I suspect the RtlVolume…() KPI.
Could you give me any tips as howto properly debug such a problem. How do i
look at the entire stack trace?
Thanks a lot,
Regards,
Samarth
“Croci, MaryBeth” wrote in message
news:xxxxx@ntdev…
>
> Two things:
>
> * With double fault, I generally look for recursion or a huge frame
> somewhere, so the last call on the stack trace isn’t enough. You need to
> look at the entire trace.
>
> * If removing a DbgPrint cures the problem, there might be something wrong
> with the statement.
>
> -----Original Message-----
> From: Samarth Sharma [mailto:xxxxx@mynetsec.com]
> Sent: Thursday, July 31, 2003 9:01 AM
> To: Windows System Software Developers Interest List
> Subject: [ntdev] Re: Double Fault
>
>
> Hi,
> Another thing, there is a DbgPrint() statement as the control is about to
> leave the function. If i remove this DbgPrint() statement then the BSOD
does
> not occur.
>
> The stack trace of the crash shows RtlpSetSecurityObject+74 as the last
> call.
>
> The handle to ObRef…() is not validated and neither is the Object pointer
> to RtlVolumeDevicetoDosName()…
> Any ideas what could be going wrong??
>
>
> Thanks,
> Samarth
>
> “Croci, MaryBeth” wrote in message
> news:xxxxx@ntdev…
> >
> > Double faults are generally due to stack overflows. Get a stack trace
to
> > debug further.
> >
> > -----Original Message-----
> > From: Samarth Sharma [mailto:xxxxx@mynetsec.com]
> > Sent: Wednesday, July 30, 2003 3:18 AM
> > To: Windows System Software Developers Interest List
> > Subject: [ntdev] Double Fault
> >
> >
> > Hi all,
> > I call ObReference…() as follows:
> >
> >
>
status=ObReferenceObjectByHandle(Handle,0,*IoFileObjectType,KernelMode,&Obje
> > ct,NULL);
> >
> > On Success this is followed by a call to RtlVolume…() which is:
> > status = RtlVolumeDeviceToDosName((PVOID)(((FILE_OBJECT
> > *)Object)->DeviceObject),Parent);
> >
> > This code sometimes causes my driver to crash with a double fault
> > UNEXPECTED_KERNEL_MODE_TRAP (7f) 8 = double fault,
> >
> > WinDbg shows the FollowupIP as RtlpSetSecurityObject+74.
> > MSDN documentation states that failure to validate object handles may
> result
> > in non-reliable driver performance. Could this be the reason for the
> crash.
> > If so, then what steps could be taken to verify the validity of objects.
I
> > want to consider only FileObject of FileSystems. In any case, don’t the
> > KPI’s themselves return an appropriate error code in case of a fault.
> >
> > I’m quite stuck,
> > Thanks
> > Samarth
> >
> >
> >
> > —
> > Questions? First check the Kernel Driver FAQ at
> > http://www.osronline.com/article.cfm?id=256
> >
> > You are currently subscribed to ntdev as: xxxxx@stratus.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@stratus.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
>
>