为什么取盘符函数在系统启动过程中只有短暂的生命？

各位专家：
  我在sfcreate例程里使用了RtlVolumeDeviceToDosName(pFileObj->DeviceObject,&dosname);
  使用了windbg工具进行跟踪；发现在第二次运行
  volume DosName is: E:
file name is:\WINDOWS\System32\Drivers\Cdaudio.SYS
volume DosName is: E:
file name is:\WINDOWS\System32\Drivers\Fs_Rec.SYS
Access violation - code c0000005 (!!! second chance !!!)
nt!IoIsOperationSynchronous+0xe:
804e9760 f6412c02         test    byte ptr [ecx+0x2c],0x2

  这时系统还没启动到桌面！如此短命！其跟踪的记录是：
在sfilter的sfcreate（）上加盘符、路径函数输出：
实验结果：windbg输出：
1 盘符与路径
volume DosName is: E:
file name is:\WINDOWS\LastGood
volume DosName is: E:
file name is:\WINDOWS\System32\ntdll.dll
volume DosName is: E:
file name is:\WINDOWS\Prefetch\NTOSBOOT-B00DFAAD.pf
volume DosName is: E:
volume DosName is: E:
volume DosName is: E:
file name is:\
…………………………………………………………………………
volume DosName is: E:
file name is:\WINDOWS\SYSTEM32\DRIVERS\CDAUDIO.SYS
volume DosName is: E:
file name is:\WINDOWS\SYSTEM32\DRIVERS\FS_REC.SYS
……………………………………………………………………………………………………………
volume DosName is: E:
file name is:\WINDOWS\System32\Drivers\Cdaudio.SYS
volume DosName is: E:
file name is:\WINDOWS\System32\Drivers\Fs_Rec.SYS
Access violation - code c0000005 (!!! second chance !!!)
nt!IoIsOperationSynchronous+0xe:
804e9760 f6412c02         test    byte ptr [ecx+0x2c],0x2

2 对应内存
804e9760 f6 41 2c 02 74 3a 8b 40 08 a8 02 0f 85 0c 4f 00  .A,.t:.@......O.
804e9770 00 b0 01 5d c2 04 00 90 90 90 90 90 8b ff 55 8b  ...]..........U.
804e9780 ec 8b 45 08 8a 4d 0c 88 08 0f b6 4d 10 c6 40 02  ..E..M.....M..@.
804e9790 04 89 48 04 83 c0 08 89 40 04 89 00 5d c2 0c 00  ..H.....@...]...
804e97a0 f6 40 08 44 75 c0 32 c0 eb c9 e8 92 db ff ff e9  .@.Du.2.........
804e97b0 7c 39 ff ff 90 90 90 90 90 33 d2 42 39 15 c8 cf  |9.......3.B9...
804e97c0 54 80 0f 85 94 35 03 00 ff 05 c8 8c 55 80 64 a1  T....5......U.d.
804e97d0 24 01 00 00 8b 88 20 02 00 00 81 c1 c8 01 00 00  $..... .........
804e97e0 e9 23 a6 ff ff 34 08 88 46 27 8d 82 e4 08 00 00  .#...4..F'......
804e97f0 89 45 08 b8 01 00 00 00 8b 4d 08 0f c1 01 e9 fd  .E.......M......
…………………………………………………………………………

3 call stack：
# ChildEBP RetAddr  Args to Child              
00 f8891a88 f833962a 81be1438 f8891cf4 804e47f7 nt!IoIsOperationSynchronous+0xe (FPO: [Non-Fpo])
01 f8891a94 804e47f7 81bdae20 81be1438 00000200 Ntfs!NtfsFsdDispatch+0xe (FPO: [Non-Fpo])
02 f8891aa4 8052efeb 81ac4470 81b94678 81b27c00 nt!IopfCallDriver+0x31 (FPO: [0,0,0])
03 f8891cf4 f888bca6 81bdae20 f889211c 00891d18 nt!IoVolumeDeviceToDosName+0x89 (FPO: [Non-Fpo])
04 f8892148 804e47f7 81bda8a0 81ac4460 81ac4460 Sfilter!SfCreate(struct _DEVICE_OBJECT * DeviceObject = 0x81bda8a0, struct _IRP * Irp = 0x81ac4460)+0x1d6 (FPO: [Non-Fpo]) (CONV: stdcall) [d:\filter\sfilter\sfilter.c @ 629]
05 f8892158 8057169a 81bdae08 81aa70ac f8892300 nt!IopfCallDriver+0x31 (FPO: [0,0,0])
06 f8892238 8056416c 81bdae20 00000000 81aa7008 nt!IopParseDevice+0xa58 (FPO: [Non-Fpo])
07 f88922c0 8056829a 00000000 f8892300 00000040 nt!ObpLookupObjectName+0x56a (FPO: [Non-Fpo])
08 f8892314 80571b73 00000000 00000000 00000000 nt!ObOpenObjectByName+0xeb (FPO: [Non-Fpo])
09 f8892390 80571c42 f8892538 00100000 f8892510 nt!IopCreateFile+0x407 (FPO: [Non-Fpo])
0a f88923ec 80571d78 f8892538 00100000 f8892510 nt!IoCreateFile+0x8e (FPO: [Non-Fpo])
0b f889242c 804df7ec f8892538 00100000 f8892510 nt!NtCreateFile+0x30 (FPO: [Non-Fpo])
0c f889242c 804dd9b1 f8892538 00100000 f8892510 nt!KiFastCallEntry+0xf8 (FPO: [0,0] TrapFrame @ f8892460)
0d f88924d0 f8988360 f8892538 00100000 f8892510 nt!ZwCreateFile+0x11 (FPO: [11,0,0])
0e f889253c f89886fd 81b18830 00000000 00000000 Fs_Rec!FsRecCreateAndRegisterDO+0x60 (FPO: [Non-Fpo])
0f f8892570 805a1799 8199d668 81a08000 e14d1738 Fs_Rec!DriverEntry+0x119 (FPO: [Non-Fpo])
10 f8892640 8069f729 0000036c 00000001 00000000 nt!IopLoadDriver+0x66c (FPO: [Non-Fpo])
11 f889269c 8069f4b1 00043000 00000000 00000000 nt!IopInitializeSystemDrivers+0x16c (FPO: [Non-Fpo])
12 f889283c 806a07f8 80087000 00000000 81bbc788 nt!IoInitSystem+0x7a3 (FPO: [Non-Fpo])
13 f8892dac 8057ce15 80087000 00000000 00000000 nt!Phase1Initialization+0x9b5 (FPO: [Non-Fpo])
14 f8892ddc 804fb4da 806a0086 80087000 00000000 nt!PspSystemThreadStartup+0x34 (FPO: [Non-Fpo])
15 00000000 00000000 00000000 00000000 00000000 nt!KiThreadStartup+0x16


请各位指点一二！
谢谢！

怎么没人进来说说！好坏给点启迪呗！
lgh@mobileelife.com

看堆栈, 错误很明显,你的这个错误发生在,当fs_rec被加载driverentry 被执行的时候,会调用status = FsRecCreateAndRegisterDO( DriverObject,
                                       L"\\Ntfs",
                                       L"\\FileSystem\\NtfsRecognizer",
                                       NtfsFileSystem );
                                       可以看nt4的源代码,这时候会ZwCreatreFile打开"\\Ntfs",
                                       被你的sfcreate截获,这个时候irsp->FileObject->DeviceObject,根本不是通常情况下的volumn DeviceObject,而是ntfs创建的control DeviceObject, 所以当你调用RtlVolumeDeviceToDosName的时候,被传到了ntfs,异常的直接原因在于FileObject为空(这个FileObject不是上面的FileOjbect, 具体可以见RtlVolumeDeviceToDosName的源码) ,根本原因还是你Attached的时候,要区分attached的是文件系统的control DeviceObject,  还是处理IRP_MJ_FILE_SYSTEM_CONTROL, IRP_MN_MOUNT_VOLUM的时候attach的文件系统mount到Volumn DeviceObject上的        DeviceObject,(有点绕嘴).你可以在DeviceExtension中区分, 对于前者,不能调用RtlVolumeDeviceToDosName,  对于后者,才可以调用RtlVolumeDeviceToDosName
 对于FileMon的方法就不会有类似的问题．