I googled and found some stuff:
http://support.microsoft.com/default.aspx?scid=kb;EN-US;Q326315
// // If the target device object is set up do direct i/o (DO_DIRECT_IO), then // IoBuildAsynchronousFsdRequest creates an MDL to describe the buffer // and locks the pages.
We also probe and lock, so it seems ros IoBuildAsynchronousFsdRequest is correct at this point. But the docs says nothing about IoBuildAsynchronousFsdRequest throwing an exception, and i have never seen any code guarding a call to IoBuildAsynchronousFsdRequest either...
googled some more:
http://drucifer.shackspace.com/bsod.txt
DRIVER_VERIFIER_IOMANAGER_VIOLATION (0xC9) 8. Call to IoBuildAsynchronousFsdRequest threw an exception 2 - the Device object 3 - the IRP major function 4 - the exception status
Hmm. So it seems IoBuildAsynchronousFsdRequest CAN throw and exception but is not allowed to do so, even thou it uses MmProbeAndLockPages! Imo, this can only mean that its not allowed to use IoBuildAsynchronousFsdRequest/IoBuildSynchronousFsdRequest with umode buffers! (MmProbeAndLockPages with kmode buffer will never fail)
Gunnar
Gunnar Dalsnes wrote:
hbirr@svn.reactos.com wrote:
- Use IoBuildAsynchronousFsdRequest instead
IoBuildSynchronousFsdRequest in NtRead/WriteFile. - Guard the calls to IoBuildAsynchronousFsdRequest with an exception frame.
Modified: trunk/reactos/ntoskrnl/io/rw.c
I dont understand these changes... Why did you change from sync. to asycn. version, and whats the point with try/except around IoBuildAsynchronousFsdRequest???
Gunnar _______________________________________________ Ros-dev mailing list Ros-dev@reactos.com http://reactos.com:8080/mailman/listinfo/ros-dev