Hi,
The ioctl handler for IOCTL_DISK_GET_DRIVE_GEOMETRY on \\.\c: in mountmgr.sys doesn't work. The call returns incorrect values that change at random intervals.
Since the ioctl is defined as METHOD_BUFFERED I think it should be putting DRIVE_GEOMETRY data in IRP->AssociatedIrp.SystemBuffer. Instead the handler puts the data in IRP->MdlAddress.StartVa. Then process_ioctl in ntoskrnl.exe wipes out the output data with the random stuff in the allocated SystemBuffer.
I am out of my depth with windows driver handling code, but a web search (http://www.cmkrnl.com/arc-ioctlbuf.html) says that SystemBuffer should be where the data is put. Indeed, when I change to SystemBuffer the user call to DeviceIoControl gets the right values back.
Am I on the right track?
Thanks, Michael Ost
PS: here's a proposed patch...
--- wine-1.1.7/dlls/mountmgr.sys/device.c.ORIG 2009-03-23 14:04:30.000000000 -0700 +++ wine-1.1.7/dlls/mountmgr.sys/device.c 2009-03-25 17:06:24.000000000 -0700 @@ -607,7 +607,7 @@ info.TracksPerCylinder = 255; info.SectorsPerTrack = 63; info.BytesPerSector = 512; - memcpy( irp->MdlAddress->StartVa, &info, len ); + memcpy( irp->AssociatedIrp.SystemBuffer, &info, len ); irp->IoStatus.Information = len; irp->IoStatus.u.Status = STATUS_SUCCESS; break;
Michael Ost wrote:
The ioctl handler for IOCTL_DISK_GET_DRIVE_GEOMETRY on \\.\c: in mountmgr.sys doesn't work. The call returns incorrect values that change at random intervals.
<snip>
List,
Never mind this one. It turns out that the bug happened due to another patch to Wine in our source tree. We adapted ntoskrnl.exe to deal with METHOD_BUFFERED driver calls, but didn't adapt mountmgr.sys for that.
Sorry for the noise! ... mo