Hi, I am a junior developer who has been placed in charge of fixing a problem we are having with a file system driver which we had developed by an external company before I joined. It’s a bit of a daunting task especially as this is my first software job and I’m in way over my head here. The problem is that the USB eject function of a USB drive which has been formatted to this file system isn’t working properly - it was working fine on Windows 10 version 1803 however does not work on the latest Windows 10.
Any attempt to either eject a USB which has been formatted to this file system or even shutdown the computer with the drive still plugged in, will result in the formatted drive being corrupted. The only way to bring it back into a usable state is to use a tool that came with the driver when it was developed which cleans the drive to make it work again.
I’m sorry if this isn’t a lot of information to go on - but I could really use someone’s help here as I am pulling my hair out trying to solve this problem. Did anything change for file system drivers in one of the latest Windows updates? If anyone has any idea what could be going on here, I would really appreciate the help!
What, exactly, do YOU consider to be “the latest Windows 10”?? 20H1? 1909??
Any attempt to either eject a USB which has been formatted to this file system
On of the first things to learn as a new developer: Try your best to be clear and precise. Describe exactly the behaviors you’re seeing: If you JUST format the drive, and do no further accesses, does the problem occur? If you format the drive and the write to it, THEN does the problem occur? If you have a pre-formatted drive, you plug it in, do not perform any data access, and THEN you eject it… does the problem occur? If you have a pre-formatted drive, you plug it in, and then you access a file on the drive (and close it), and THEN you eject it… does the problem occur?
When you eject the drive (presumably with Explorer?) does the eject “succeed” (according to Explorer)? Or does it fail to eject the drive (“The drive is currently in use… blah blah”)?
So, it certainly sounds like the file system is failing to flush its data to disk and to release its in-memory data structures.
Do you have the source code for this file system? Cuz, if not…there’s little chance of you changing its behavior. Unless you want to write a file system filter to do so. If you can even do that…
Thank you for your message, I will try to answer your questions as best I can - really appreciate the ideas you have given so far.
Issue is occurring on Windows 10 Pro 1909.
If I format the drive - no problems occur. Windows recognises the drive and shows it is using the file system under properties menu of the drive.
If I format the drive and then write to it, again no problems occur. Even when the drive is ejected (which then becomes inaccessible), if I use the tool that came with the driver to “clean” the drive, the drive becomes accessible again and all the files written to it are still present on the drive.
If I have a pre-formatted drive, plug it in, do not attempt access on it and eject it straight away, the problem will occur.
If I have a pre-formatted drive, plug it in and then attempt to access files on the drive, close it then eject - the problem will occur.
When I eject the drive through the context menu in Explorer, the eject is successful according to Windows i.e. the drive is removed from Explorer and “It is now safe to remove…” message is displayed.
I do have access to the source code for this file system driver. Would you be able to provide further information on how I can repair the flush/release process if that might be what is causing the issue? Again, thanks for your help so far.
I don’t know of any changes in this area that would explain why your FSD doesn’t dismount properly anymore.
Does your driver support IRP_MN_QUERY_REMOVE_DEVICE? That’s usually the place where the file system flushes everything out so that the volume is in a known good state before the remove. You’ll also need to look at both explicit (FSCTL_LOCK_VOLUME) and implicit (volume open with no share) volume locking because file systems often also flush things in these cases.
If your device reports itself as having removable media (e.g. a CD-ROM) things are a bit different because you’ll usually see a volume lock followed by an IOCTL_STORAGE_EJECT_MEDIA (or variant).
Something I have noticed: If I remove IRP_MJ_DEVICE_CONTROL from IrpDispatch method, the eject works but Windows Explorer doesn’t show the drive straight away when it is plugged in, I have to refresh Explorer by closing it or switching to another folder and back for the drive to show. Can anyone explain why disabling this IRP causes the eject to work properly?
Sorry, but you can’t just try random things…Not handling ANY IOCTLs is going to be bad. This disables them not only for you but for the volume and disk as well. I’m surprised Windows is happy with the drive at all when you do this.
My previous questions stand. You need to figure out how the code is supposed to handle dismount/remove/eject and trace what’s going on. Windows file system can be really, REALLY complicated so expect this to take some time if you have no experience in this space (especially with no access to the original developers).