ShellExecute and open references

This is a discussion on ShellExecute and open references within the Windows Programming forums, part of the Platform Specific Boards category; Hello, first of all sorry for the vague title - I'm just not quite sure what the exact problem is. ...

  1. #1
    not-a-geek
    Join Date
    Apr 2004
    Posts
    210

    ShellExecute and open references

    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

  2. #2
    C++まいる!Cをこわせ! Elysia's Avatar
    Join Date
    Oct 2007
    Posts
    22,422
    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.
    Quote Originally Posted by Adak View Post
    io.h certainly IS included in some modern compilers. It is no longer part of the standard for C, but it is nevertheless, included in the very latest Pelles C versions.
    Quote Originally Posted by Salem View Post
    You mean it's included as a crutch to help ancient programmers limp along without them having to relearn too much.

    Outside of your DOS world, your header file is meaningless.

  3. #3
    not-a-geek
    Join Date
    Apr 2004
    Posts
    210
    Quote Originally Posted by Elysia View Post
    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...

  4. #4
    C++まいる!Cをこわせ! Elysia's Avatar
    Join Date
    Oct 2007
    Posts
    22,422
    Quote Originally Posted by Nyda View Post
    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?
    Quote Originally Posted by Adak View Post
    io.h certainly IS included in some modern compilers. It is no longer part of the standard for C, but it is nevertheless, included in the very latest Pelles C versions.
    Quote Originally Posted by Salem View Post
    You mean it's included as a crutch to help ancient programmers limp along without them having to relearn too much.

    Outside of your DOS world, your header file is meaningless.

  5. #5
    not-a-geek
    Join Date
    Apr 2004
    Posts
    210
    Quote Originally Posted by Elysia View Post
    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 ...

    Quote Originally Posted by Elysia View Post
    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.

  6. #6
    C++まいる!Cをこわせ! Elysia's Avatar
    Join Date
    Oct 2007
    Posts
    22,422
    Quote Originally Posted by Nyda View Post
    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.
    Quote Originally Posted by Adak View Post
    io.h certainly IS included in some modern compilers. It is no longer part of the standard for C, but it is nevertheless, included in the very latest Pelles C versions.
    Quote Originally Posted by Salem View Post
    You mean it's included as a crutch to help ancient programmers limp along without them having to relearn too much.

    Outside of your DOS world, your header file is meaningless.

  7. #7
    not-a-geek
    Join Date
    Apr 2004
    Posts
    210
    Quote Originally Posted by Elysia View Post
    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!
    main() { int O[!0<<~-!0]; (!0<<!0)[O]+= ~0 +~(!0|!0<<!0); printf("a function calling "); }

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. ShellExecute() doesn't work
    By Overlord in forum Windows Programming
    Replies: 6
    Last Post: 04-22-2007, 04:00 AM
  2. ShellExecute() & EnumWindows()?
    By geek@02 in forum Windows Programming
    Replies: 1
    Last Post: 09-19-2005, 09:41 PM
  3. ShellExecute error handling
    By BianConiglio in forum Windows Programming
    Replies: 2
    Last Post: 07-09-2005, 03:20 PM
  4. ShellExecute, strange !!
    By BianConiglio in forum C Programming
    Replies: 2
    Last Post: 05-05-2004, 04:41 AM
  5. ShellExecute Problem
    By dhrodrigues in forum Windows Programming
    Replies: 2
    Last Post: 04-12-2004, 03:17 PM

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21