I know this is late for metzler, but may help others...
I did a search for command-line methods for ejecting USB drives, and ran across a PowerShell script that works (usually). It can be converted to LabVIEW (I included the script and details for setting the ActiveX class in the snippet):
Most of the blocks are off the Connectivity/ActiveX palette. I don't know what '17' means. And 'E:' is the drive I want to eject.
This is effectively the same as right-clicking the 'E:' drive in windows Explorer, and then clicking 'Eject'. I have a virus scanner that takes over every drive I insert, so when I use this, I get a pop-up: "'Removable Disk (E:)' is currently in use...", but does give me a "Continue" button so I can eject it safely in spite of the virus scanner. For many systems, it won't pop up anything, and the disk will disappear out of Explorer. On my system, it disappears from the tree view, but not the file view for some reason.
Not perfect, but I like it better than pulling the drive without an 'eject' at all.
BTW, you're right to be concerned about Windows randomly accessing your drive. Virus scanners (and built-in tools) do it all the time. But most of them only read. As long as it isn't writing, you're usually safe.
FAT systems (most thumb drives) write to files using a method that is prone to errors. They write the data in an unused area, then go back to a table of 'used' blocks, and records how to find each block of data. If something goes wrong before writing the table ("File Allocation Table"), the last file written can be corrupted or lost. If something goes wrong WHILE writing the table, a lot of files can get corrupted. Luckily, there are 2 copies of the FAT, so if it messes up while writing one, the other should work as a backup... 'Should'. Usually the write to the FAT (both copies) is so quick after the write to the data, that it's safe. And the drive should know to finish writing one sector as the drive is being removed (see post before about power pins in USB).
Another issue with FAT is that many systems (I'm sure Windows does) write a flag saying it is 'dirty' the first time you write to it. It doesn't mark it 'clean' till you 'eject' properly. So every time you use the drive on a system configured to complain about dirty drives, it will ask to scan & search for issues. Frankly, I haven't looked into it in a long time, so this might be obsolete. From my experience, it looks like Windows marks the drive 'clean' after a while of no use. So I don't get the 'scan & search for issues' pop-up very often.
Note: The solution I offered doesn't compile or run in windows 10. I was able to compile it in Windows 10 by re-picking the Shell32.IShellDispatch6 (by the exact same object). But whenever I run it, I get error 3008 from the invoke-NameSpace(17), "Automation Interface for the specified class cannot be obtained..." I've asked for help on another thread, and hope I remember to post any answer here, too.