I found a very strange problem.
my filter will work well in many WinXP,but in some WinXP(maybe add some hotfix),my filter will meet a strange recursive IRP_MJ_CREATE.
I will describe it by the following example:
1.explorer.exe (PID 380,TID 1180) open D:\1.txt
in my filter,I meet a IRP_MJ_CREATE for D:\1.txt
2.In this IRP_MJ_CREATE,I will call IoCreateFileSpecifyDeviceObjectHint for D:\1.txt ,
I issue it in the same thread context(PID 380,TID 1180).
3.I will meet many recursive IRP_MJ_CREATE!
these IRP_MJ_CREATE is for:
C:\desktop.ini
C:\documents and settings.…\desktop.ini
…
D:\desktop.ini
anybody call clear it?thanks!
Is it really a recursive create, i.e. if you list call stack,
is your call to IoCreateFileSpecifyDeviceObjectHint there ?
L.
No!
because the thread context has switched.
My original call is at (PID 380,TID 1180).
the recursive IRP_MJ_CREATE is at (PID 380,TID 588).
PID 380 is explorer.exe
But in my filter,I will lock it when IRP_MJ_CREATE,so deadlock
>No!
because the thread context has switched.
My original call is at (PID 380,TID 1180).
the recursive IRP_MJ_CREATE is at (PID 380,TID 588).
PID 380 is explorer.exe
But in my filter,I will lock it when IRP_MJ_CREATE,so deadlock
How can you call it recursive if it is in the context of another thread?
Explorer might be having multiple threads.
Regards,
Ayush Gupta
the recursive IRP_MJ_CREATE is not issued directly by my filter.
my means is:
1.when I click the file D:\1.txt ,the explorer.exe process issued a IRP_MJ_CREATE for D:\1.txt
2.My filter meet the IRP_MJ_CREATE,so I call IoCreateFileSpecifyDeviceObjectHint for D:\1.txt in the same thread context
3.after I call IoCreateFileSpecifyDeviceObjectHint,the function can’t return!
before the function returned,the explorer.exe process will issued another IRP_MJ_CREATE for XXX\desktop.ini in another thread context.
I think,the possible cause is:
1.the IO Manager mentions my call(IoCreateFileSpecifyDeviceObjectHint),it … issued those IRP_MJ_CREATE for the desktop.ini (and IRP_MJ_Cleanup,IRP_MJ_Close).
2.Virus!the Virus hooked the functiontable of the FSD driverobject.
So,my call issued a IRP_MJ_Create to the FSD.the virus get the control,so it issued other operation.But I scan the system by many anti-virus,they reports no virus.
xxxxx@hotmail.com wrote:
the recursive IRP_MJ_CREATE is not issued directly by my filter.
my means is:
1.when I click the file D:\1.txt ,the explorer.exe process issued a IRP_MJ_CREATE for D:\1.txt
2.My filter meet the IRP_MJ_CREATE,so I call IoCreateFileSpecifyDeviceObjectHint for D:\1.txt in the same thread context
3.after I call IoCreateFileSpecifyDeviceObjectHint,the function can’t return!
before the function returned,the explorer.exe process will issued another IRP_MJ_CREATE for XXX\desktop.ini in another thread context.
That looks normal to me. You have to handle reentrancy, since any
driver can be called back at any time.
You can also get multiple threads calling the same function at the same
time (on a multicore system, at *exactly* the same time) - you need to
handle that too.
Tony
I have handled it!
If multi thread of the explorer.exe issued IRP_MJ_CREATE,I can handled it!please visit IFS FAQ#34,there are many ways.
But in my question,my IoCreateFileSpecifyDeviceObjectHint issued other IRP_MJ_CREATE in other thread context!We use IoCreateFileSpecifyDeviceObjectHint to avoid recursive IRP_MJ_CREATE,but in my question,the IoCreateFileSpecifyDeviceObjectHint call will issued other IRP_MJ_CREATE to my filter!
My filter works well in WinXP,Win2K,Win2003,but in some strange WinXP,it can’t work,the cause is the above!
There is a known bug in IoCreateFileSpecifyDeviceObjectHint right up to
Vista (and possibly beyond) which means that you *will*get called back
re-entrantly even on the same stack.
ISTR that it has something to do with relative opens.