CreateFile hangs after RM insertion.

NTFSD
1

Hello.
I am new in driver development. Our product consist of one FS filter driver and some drivers(let’s call it OurProduct). Our product is not compatable with another product (from another vendor). Let’s call it OtherProduct. OtherProduct has one FS filter driver and 4 drivers. After a USB stick insertion,
HANDLE hDevice = CreateFile(L"\\.\PhysicalDrive0",
GENERIC_READ | GENERIC_WRITE,
FILE_SHARE_READ | FILE_SHARE_WRITE | FILE_SHARE_DELETE,
NULL,
OPEN_EXISTING,
0,
NULL);
call hangs. When I remove (delete) FS filter driver of OtherProduct, everything works good.

Can you explain me the reason of this behavior?

[May be this can help]:

I have used IrpTracker.exe and so that FS filter driver of OtherProduct is not get any IRP. This is used when other components of that product are installed.

I have used DeviceTree.exe and have seen that FS filter driver of OtherProduct is not under the stack of FileSystem\Ntfs, but our driver is there.

Thank you…

2

> Can you explain me the reason of this behavior?

What will !process 0 7 say?

–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com

3

May be I have done something wrong but “!process 0 7” on local kernel debugger hangs on windbg.exe .
What can say “!process 0 7” ? Does it print information about drivers?

4

> What can say “!process 0 7” ? Does it print information about drivers?

It prints all stacks in system. A slow command for serial link, but more or less OK for 1394 or for a dump.

So, initiate a crash dump of the hung machine using CrashOnCtrlScroll, and then use “windbg -z”.

–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com

5

When I initiate crash dump by Ctrl + Scroll Lock + Scroll Lock (after RM insertion), windbg analizer gives

MANUALLY_INITIATED_CRASH (e2)
The user manually initiated this crash dump.
Arguments:
Arg1: 00000000
Arg2: 00000000
Arg3: 00000000
Arg4: 00000000

Whitout Ctrl + Scroll Lock + Scroll Lock no dumps are created. Must it be created when BSOD occures? In my case there is no BSOD.

6

Can you help me with this question: how can I detect the specified call of CreateFile:
CreateFile(L"\\.\PhysicalDrive0",
GENERIC_READ | GENERIC_WRITE,
FILE_SHARE_READ | FILE_SHARE_WRITE | FILE_SHARE_DELETE,
NULL,
OPEN_EXISTING,
0,
NULL);

When receiving IRP_MJ_CREATE, what field can show that \.\PhysicalDrive0 is being opened?

7

Yes, forcing a bug check is how the manual crash dump support works.

  • S

-----Original Message-----
From: xxxxx@gmail.com
Sent: Tuesday, May 12, 2009 06:41
To: Windows File Systems Devs Interest List
Subject: RE:[ntfsd] CreateFile hangs after RM insertion.

When I initiate crash dump by Ctrl + Scroll Lock + Scroll Lock (after RM insertion), windbg analizer gives

MANUALLY_INITIATED_CRASH (e2)
The user manually initiated this crash dump.
Arguments:
Arg1: 00000000
Arg2: 00000000
Arg3: 00000000
Arg4: 00000000

Whitout Ctrl + Scroll Lock + Scroll Lock no dumps are created. Must it be created when BSOD occures? In my case there is no BSOD.

—
NTFSD is sponsored by OSR

For our schedule of debugging and file system seminars
(including our new fs mini-filter seminar) visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

8

I have used this:
PFILE_OBJECT fileObject = thisIrpStack->FileObject;
DbgPrint(“Opened File %S \n”, fileObject->FileName.Buffer);

Among many other lines sometimes I get

Opened File (null) or
Opened File \

Is one of them indicates \.\PhysicalDrive0 ?

9

The path you can see in filter is relative to the device name which are you attached to. This device is registered into Object Manager under its name (see IoCreateDevice). Note that there are also unnamed devices. To attach to one device stack, you must have one device instance. You can inspect device by !devobj comand.

I think that \.\PhysicalDriveX is Disk device, it is not File System device, so you cannot attach to it by a File System Filter.

You can analyze crash dump you have created post mortem. To debug it in live session you must have two machines. One or both of them can be virtual.

Expect very long way. Nobody here will you describe everything in details. You must do your home work, which could take months.

Good luck
Bronislav Gabrhelik

10

Thank you very much. I’ll try…

11

Hello. I’m back with a question.
I found an interesting snip of code in our driver.
In our device control routine (IRP_MJ_DEVICE_CONTROL), if IoControlCode is IOCTL_MOUNTDEV_LINK_CREATED (this comes after RM insertion) we forword IRP by the scenario 4 in http://support.microsoft.com/kb/320275. And in CompletionRoutine we return STATUS_MORE_PROCESSING_REQUIRED.
Here is the most interesting part: we call IoCompleteRequest() only when RM is going to be removed.

I have read http://www.osronline.com/article.cfm?id=83 article. May be I am wrong but here is my opinion (what I have understood):

IRP_MJ_DEVICE_CONTROL goes down till the lowest driver, it calls IoCompleteRequest(), one step upper driver’s CompletionRoutine is called, so on, our CompletionRoutine is called. We return STATUS_MORE_PROCESSING_REQUIRED, and lowest level driver’s IoCompleteRequest() returns.
If there is a driver upper to ours, it’s CompletionRoutine will not be called until RM is removed
(that means until our call of IoCompleteRequest()).

Am I right?

Thank you…