ShellExecute and open references

**Nyda** · 08-06-2009

Hello,

first of all sorry for the vague title - I'm just not quite sure what the exact problem is.

My programm is trying to dismount the thumb-drive from which it is being executed. To be able to do this, it first copies itself to the system's temp-folder (using CopyFile) and launches the new instance of itself (using ShellExecuteEx) from there before exiting. The new instance then tries to dismount the drive.
Since you're reading this you can imagine it didn't work

. I'm guessing Windows still has some kind of reference to the original instance of my application, but I don't know what that would be since I'm not requesting a process handle from ShellExecuteEx (meaning I'm not using SEE_MASK_NOCLOSEPROCESS). I've tried launching the application manually directly from the temp folder and this works as intended (drive dismounts properly).

This is how ShellExecuteEx is being used in my application...

Code:

[...]
  SHELLEXECUTEINFO sei;
  ZeroMemory(&sei, sizeof(sei));
  sei.cbSize      = sizeof(sei);
  sei.lpFile      = filename; // was passed in as function parameter
  sei.lpParameters= param; // same
  sei.nShow       = SW_SHOW;
  sei.fMask       = SEE_MASK_FLAG_NO_UI;
[...]
  sei.lpVerb      = "open";
[...]
  if (!ShellExecuteEx(&sei))
    return FALSE;
[...]

I've also verified that the original instance that was launched from the drive is no longer running after these lines of code.
Any hints, comments, ideas would really be appreciated. Thank you

**Elysia** · 08-07-2009

I would try to get the error from the function that dismounts the thumbdrive instead.
There is no such thing as "reference" to original executable. It's a copy of the original executable now, so there's two. Two copies.

**Nyda** · 08-07-2009

Originally Posted by Elysia

I would try to get the error from the function that dismounts the thumbdrive instead.
There is no such thing as "reference" to original executable. It's a copy of the original executable now, so there's two. Two copies.

Thanks Elysia. That's not quite what I meant with 'reference', though. I was thinking that windows might still have some sort of handle to the application on the thumbdrive which launched the second instance from the temp directory.

As for the dismounting itself, I seem to be getting a CR_SUCCESS from CM_Request_Device_Eject. Odd. Maybe I'm missing an error somewhere along the chain. I guess I'll have to go through all that code, too. Windows programming is really my favourite pastime...

**Elysia** · 08-07-2009

Originally Posted by Nyda

Thanks Elysia. That's not quite what I meant with 'reference', though. I was thinking that windows might still have some sort of handle to the application on the thumbdrive which launched the second instance from the temp directory.

Well, that's what I was implying - if launching the exe in the temp directory, it won't be a handle to the original file on the thumb drive, but a handle to the temp dir exe, so if the program on the temp drive closes later, there will be no references to (no handles) the original file.

As for the dismounting itself, I seem to be getting a CR_SUCCESS from CM_Request_Device_Eject. Odd. Maybe I'm missing an error somewhere along the chain. I guess I'll have to go through all that code, too. Windows programming is really my favourite pastime...

Nor is it mine, but monitor all the calls to the API calls and see if any fails and probably post the code so others could test or try to find some insight.
Are you sure that the drive isn't dismounted?

**Nyda** · 08-08-2009

Originally Posted by Elysia

Well, that's what I was implying - if launching the exe in the temp directory, it won't be a handle to the original file on the thumb drive, but a handle to the temp dir exe, so if the program on the temp drive closes later, there will be no references to (no handles) the original file.

Is there some equivalent to the *nix command lsof that I could use to see if there are still open files/handles on the thumbdrive? I added a Sleep(...) to the end of my application and tried to use windows' "safely remove" function while the application was still sleeping. This also failed. I've also verified again, that I'm really running the copy from the temp-folder and not the original file from the thumbdrive and that the first instance launched from the drive was properly terminated. I'm at a loss

...

Originally Posted by Elysia

Nor is it mine, but monitor all the calls to the API calls and see if any fails and probably post the code so others could test or try to find some insight

I used sample code for usb-device ejection which was published in CT-Magazine a couple of years ago. It's more than 20K of code and works flawlessley when manually called from my temp directory, so I'm confident it's not the cause of the problem. Though if you're interested I could probably find the link to the sourcecode again.

Just in case you or anyone else wonders what the whole point of the excercise is: The application is "burned" on the u3-cd-autostart partion of my thumbdrive. When the drive is plugged in, a TrueCrypt prompt appears and upon entering the proper password, the TC partition is being mounted and a startmenu like application called PortableApps is launched from the TC partition. When I exit the menu, all applications launched from the TC volume close, the volume dismounts and finally the thumbdrive is supposed to dismount too. The last part is obviously not working yet.

**Elysia** · 08-08-2009

Originally Posted by Nyda

Is there some equivalent to the *nix command lsof that I could use to see if there are still open files/handles on the thumbdrive? I added a Sleep(...) to the end of my application and tried to use windows' "safely remove" function while the application was still sleeping. This also failed. I've also verified again, that I'm really running the copy from the temp-folder and not the original file from the thumbdrive and that the first instance launched from the drive was properly terminated. I'm at a loss

...

Try Unlocker for x86 or LockHunter for x64. They are both applications that can identify and terminate locks on directories and files.
I doubt there is a command to do what you want.

I used sample code for usb-device ejection which was published in CT-Magazine a couple of years ago. It's more than 20K of code and works flawlessley when manually called from my temp directory, so I'm confident it's not the cause of the problem. Though if you're interested I could probably find the link to the sourcecode again.

Just in case you or anyone else wonders what the whole point of the excercise is: The application is "burned" on the u3-cd-autostart partion of my thumbdrive. When the drive is plugged in, a TrueCrypt prompt appears and upon entering the proper password, the TC partition is being mounted and a startmenu like application called PortableApps is launched from the TC partition. When I exit the menu, all applications launched from the TC volume close, the volume dismounts and finally the thumbdrive is supposed to dismount too. The last part is obviously not working yet.

I suspect TotalCrypt itself is locking the volume! That makes sense, as it is a virtual drive which TotalCrypt creates. You probably have to go another way around this to make it work.

**Nyda** · 08-09-2009

Originally Posted by Elysia

Try Unlocker for x86 or LockHunter for x64. They are both applications that can identify and terminate locks on directories and files.
I doubt there is a command to do what you want.

Thanks for the unlocker link. Though Unlocker didn't do the trick, they have a really great list of related software on that site. I downloaded ProcessExplorer (I think I even used this one some time ago but forgot about it).

ProcessExplorer shows that my application really holds an open handle on the cd-partition of my thumbdrive (the unencrypted partition that contains TC and my application). Using PE I can close that handle and then the dismounting actually works.

So the question was, where does it come from. I noticed PE lists the working directory of my application as the root directory of the cd-partition. Uh? Seems like I forgot to specify a working directory in the ShellExecuteEx parameter structure and it defaulted to the current one - the thumbdrive's root directory where it all started.

I've fixed this now and everything works properly. In a sense, the original instance really caused the new one to have an open handle on the thumbdrive.

Thanks for all your feedback Elysia!

Thread: ShellExecute and open references

Thread Tools

Search Thread

Display

ShellExecute and open references

Similar Threads

ShellExecute() doesn't work

ShellExecute() & EnumWindows()?

ShellExecute error handling

ShellExecute, strange !!

ShellExecute Problem