I have have a couple of instances of this bugcheck recently and the first parameter is the same, which I believe is the file identifier, I read that the first 16 bit is the file id which is 0019, all I want to know is how do I find the file object for this file id? is it possible? I’m mainly after the filename.
Thanks in advance
adam.
it’s ID of ntfs file source – e.g. ntfs\read.c (etc.)
so it’s not possible to convert this id to fileobject
try to use .cxr with 3rd parameter and figure out why it crashed
wrote in message news:xxxxx@ntfsd…
>I have have a couple of instances of this bugcheck recently and the first
>parameter is the same, which I believe is the file identifier, I read that
>the first 16 bit is the file id which is 0019, all I want to know is how do
>I find the file object for this file id? is it possible? I’m mainly after
>the filename.
>
> Thanks in advance
>
> adam.
>
>
Thanks for your reply.
doing what you say I get the following:
7: kd> .cxr f62ce364
eax=0000007a ebx=00000000 ecx=83509ff4 edx=00000000 esi=82eedcd8 edi=f62cea4c
eip=80883260 esp=f62ce730 ebp=f62ce730 iopl=0 nv up ei ng nz ac po nc
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00010292
nt!wcscpy+0xb:
80883260 668b02 mov ax,word ptr [edx] ds:0023:00000000=???
7: kd> k
*** Stack trace for last set context - .thread/.cxr resets it
ChildEBP RetAddr
f62ce730 f65c0e7d nt!wcscpy+0xb
WARNING: Stack unwind information not available. Following frames may be wrong.
f62ce838 f65c15fe VsrFsJnl+0x7e7d
f62ce878 f65ca189 VsrFsJnl+0x85fe
f62cea54 f6c63cdf VsrFsJnl+0x11189
f62cea78 f6c63ee0 VsrFsFlt!OsrFilterStatistics+0xaf
f62ceaac 8081e057 VsrFsFlt!OsrFilterStatistics+0x2b0
f62ceadc f7171b6d nt!IopfCompleteRequest+0xcd
f62ceaec f719d63a Ntfs!NtfsCompleteRequest+0xc8
f62ceb50 f71702fb Ntfs!NtfsCommonSetInformation+0x4f6
f62cebb8 8081deb9 Ntfs!NtfsFsdSetInformation+0xa3
f62cebcc f725585a nt!IofCallDriver+0x45
f62cebe0 f7255cf1 fltMgr!FltpPassThrough+0x12c
f62cec10 8081deb9 fltMgr!FltpDispatch+0x10d
f62cec24 f6c63196 nt!IofCallDriver+0x45
f62cec2c f6c6445c VsrFsFlt+0x1196
f62cecac 8081deb9 VsrFsFlt!OsrFilterStatistics+0x82c
f62cecc0 808f0bbf nt!IofCallDriver+0x45
f62ced48 808893fc nt!NtSetInformationFile+0x5ab
f62ced48 7c82ed54 nt!KiFastCallEntry+0xfc
0173b0a4 7c821e24 ntdll!KiFastSystemCallRet
I understand that the error is because that instuction is trying to read from memory addr 0x00000000 but how do I figure out who caused it?
doing !process shows one process is this the process that caused the crash?
sorry, I’m new to this!
wrote in message news:xxxxx@ntfsd…
> Thanks for your reply.
>
> doing what you say I get the following:
>
> 7: kd> .cxr f62ce364
> eax=0000007a ebx=00000000 ecx=83509ff4 edx=00000000 esi=82eedcd8
> edi=f62cea4c
> eip=80883260 esp=f62ce730 ebp=f62ce730 iopl=0 nv up ei ng nz ac po
> nc
> cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000
> efl=00010292
> nt!wcscpy+0xb:
> 80883260 668b02 mov ax,word ptr [edx]
> ds:0023:00000000=???
> 7: kd> k
> *** Stack trace for last set context - .thread/.cxr resets it
> ChildEBP RetAddr
> f62ce730 f65c0e7d nt!wcscpy+0xb
> WARNING: Stack unwind information not available. Following frames may be
> wrong.
> f62ce838 f65c15fe VsrFsJnl+0x7e7d
> f62ce878 f65ca189 VsrFsJnl+0x85fe
> f62cea54 f6c63cdf VsrFsJnl+0x11189
> f62cea78 f6c63ee0 VsrFsFlt!OsrFilterStatistics+0xaf
> f62ceaac 8081e057 VsrFsFlt!OsrFilterStatistics+0x2b0
> f62ceadc f7171b6d nt!IopfCompleteRequest+0xcd
> f62ceaec f719d63a Ntfs!NtfsCompleteRequest+0xc8
> f62ceb50 f71702fb Ntfs!NtfsCommonSetInformation+0x4f6
> f62cebb8 8081deb9 Ntfs!NtfsFsdSetInformation+0xa3
> f62cebcc f725585a nt!IofCallDriver+0x45
> f62cebe0 f7255cf1 fltMgr!FltpPassThrough+0x12c
> f62cec10 8081deb9 fltMgr!FltpDispatch+0x10d
> f62cec24 f6c63196 nt!IofCallDriver+0x45
> f62cec2c f6c6445c VsrFsFlt+0x1196
> f62cecac 8081deb9 VsrFsFlt!OsrFilterStatistics+0x82c
> f62cecc0 808f0bbf nt!IofCallDriver+0x45
> f62ced48 808893fc nt!NtSetInformationFile+0x5ab
> f62ced48 7c82ed54 nt!KiFastCallEntry+0xfc
> 0173b0a4 7c821e24 ntdll!KiFastSystemCallRet
>
> I understand that the error is because that instuction is trying to read
> from memory addr 0x00000000 but how do I figure out who caused it?
>
> doing !process shows one process is this the process that caused the
> crash?
>
> sorry, I’m new to this!
>
>
Perhaps I missed something further upthread, but the problem is in an
unfortunate call to wcscpy in the VsrFsJnl, which I am hoping is code you
own or code you can get direct support from the vendor on. VsrFsJnl should
not be calling wcscpy at all as it is considered unsafe, it shouldl instead
be using RtlStringCbCopyW*,* RtlStringCbCopyW and all wide string methods
are actually restricted to passive level due to code page issues (grrr…)
and with the proper symbols the source code owner should be able to
determine from this crash exactly where VsrFsJnl is losing its brains. It is
pretty much irrelevant what the filename is or what ntfs is up to.
On Jan 5, 2008 3:11 PM, Petr Kurtin wrote:
> it’s ID of ntfs file source – e.g. ntfs\read.c (etc.)
> so it’s not possible to convert this id to fileobject
>
> try to use .cxr with 3rd parameter and figure out why it crashed
>
>
> wrote in message news:xxxxx@ntfsd…
> >I have have a couple of instances of this bugcheck recently and the first
> >parameter is the same, which I believe is the file identifier, I read
> that
> >the first 16 bit is the file id which is 0019, all I want to know is how
> do
> >I find the file object for this file id? is it possible? I’m mainly after
> >the filename.
> >
> > Thanks in advance
> >
> > adam.
> >
> >
>
>
>
> —
> NTFSD is sponsored by OSR
>
> For our schedule debugging and file system seminars
> (including our new fs mini-filter seminar) visit:
> http://www.osr.com/seminars
>
> You are currently subscribed to ntfsd as: xxxxx@hollistech.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
–
Mark Roddy
Thanks for all your help and don’t worry about the questions below but if you can be bothered.
This is 3rd party vendor code so I do not have the symbols, I will look to them for support on this issue though.
Just to get things right in my own head. It was definately the fault of VsrFsJnl? making an unsafe call to wcscpy where either the src or dest string is pointing to 0x00000000.
How do I learn things like wcscpy has been replaced?
I probably should have left out the detail that processing wide char strings
in this code path is problematic as it may not be relevant to the actual
crash. That was a side note based on my assumption that you were
representing the developer of the software.
What is clear is that VsrFsJnl is crashing processing a wide char string in
a call to wcscpy, and that is what I would take to the driver vendor. If you
have a crash dump and/or a reproducible test case, they should be able to
root cause the bug and fix it.
Unless you are writing device drivers you probably would not know that
Microsoft has been trying to discourage the use of standard C lib string
processing routines in kernel code for the last few years as they are
considered a security risk and a source of numerous bugs. The information
about this is in the Wdk. They actually have an identical campaign up in
user mode for the same reasons.
On Jan 6, 2008 3:14 PM, wrote:
> Thanks for all your help and don’t worry about the questions below but if
> you can be bothered.
>
> This is 3rd party vendor code so I do not have the symbols, I will look to
> them for support on this issue though.
>
> Just to get things right in my own head. It was definately the fault of
> VsrFsJnl? making an unsafe call to wcscpy where either the src or dest
> string is pointing to 0x00000000.
>
> How do I learn things like wcscpy has been replaced?
>
>
>
>
> —
> NTFSD is sponsored by OSR
>
> For our schedule debugging and file system seminars
> (including our new fs mini-filter seminar) visit:
> http://www.osr.com/seminars
>
> You are currently subscribed to ntfsd as: xxxxx@hollistech.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
–
Mark Roddy
Thanks again, case closed!