You are not logged in.
This is a fun one to try to explain.
I have an exe that I've written in C#. This is to run on a 'cart'. which is a separate machine (e.g. not my pc). The cart runs Windows 7 embedded, and for all practical purposes (as far as I know) behaves exactly like a standard version of Windows 7.
My exe is nothing more than a middleman himself, designed to allow a user to select a few options and then call an exe on the hard drive of the cart with the appropriate arguments. It calls a tool that gets a new version of our cart's primary software product over the network and install it over top of what's currently there.
The users in my group who will use this aren't always the most computer savvy, so I try to make it a one-click operation. They bring files (like my software) the cart by USB sticks. They can't leave the USB stick in the drive because after the software install happens, the computer reboots and will try to boot to the USB stick if left in.
So I need the exe to be copied over to the hard drive and then run from there. So I wrote a simple batch file that was something like this:
xcopy /v /f /y .\SITData\NightlyBuildInstaller.exe c:\temp
start c:\temp\NightlyBuildInstaller.exe
exit
However, once NightlyBuildInstaller.exe starts, there is still some hold on the USB drive and it won't let me eject. I verify this by using SysInternals ProcessExplorer tool. NightlyBuildInstaller.exe is the culprit. Why does it still have a lock on the USB drive?
I've tried other variations like using "cmd /c" or "cmd /k" or even putting "&" at end of command to run in background, but no matter what I try, there is still a lock the USB drive.
Oh...another piece of information. When you click the "continue" when USB stick show's it's locked so that it forces the eject, that seems to fail the software install. Somewhere deep in the tool, (found through a HUGE procmon log dump) it fails due to trying to reference that now non-existent USB drive.
Any ideas why and/or how to get around this?
Last edited by kingtermite (26 Oct 2017 21:44)
Offline
Try changing the current directory away from the USB.
xcopy /v /f /y .\SITData\NightlyBuildInstaller.exe c:\temp
cd /d c:\temp
start NightlyBuildInstaller.exe
I've tried other variations like [...] "&" at end of command to run in background
This is a Bash feature.
Last edited by Pyprohly (27 Oct 2017 03:47)
Offline
Try changing the current directory away from the USB.
xcopy /v /f /y .\SITData\NightlyBuildInstaller.exe c:\temp cd /d c:\temp start NightlyBuildInstaller.exe
kingtermite wrote:I've tried other variations like [...] "&" at end of command to run in background
This is a Bash feature.
Thanks. Will try that and let you know.
& is only a Bash feature? I guess I've been doing this too long and it runs together eventually.
Offline
Try this:
xcopy /v /f /y .\SITData\NightlyBuildInstaller.exe c:\temp
cd /D c:\temp
(
echo Remove the USB stick now and
pause
start NightlyBuildInstaller.exe
exit
)
The parenthesized code block of commands read them in memory first and then execute them. In the worst case you may get a "Batch file not found" or similar error message, but the execution of the installer begins when the USB is not longer inserted...
Offline
Thank you, Pyprohly. You were exactly right and that led me to "understand the problem" (the most important part).
The second EXE that I was starting was starting with the same Environment context as my EXE which had the USB set as it's Current Working Directory (CWD). I changed current working directory within my EXE and was able to get rid of the stupid middle man BATCH file altogether. So stoked about that because it seemed like such a kludge to begin with.
Thank you very much.
Offline