How do I recover the window handle passed to ShellExecute?

A customer had the following question:

I'm using the ShellExecute function to launch a new process and am passing the handle to my application's main window as the hwnd parameter. From the new process, I want to get information from the old process, and to do that, I need the window handle. How can I recover that window handle from the new process?

You can't.

That window handle is used by the ShellExecute function only to host any user interface operations that occur as a result of the attempt to execute the program. For example, it is the owner window used for any error dialogs. The ShellExecute function does not pass the window handle to the launched process. (It couldn't even if it wanted to: There is nowhere to pass it. There is no window handle among the parameters to CreateProcess nor is there a window handle in the STARTUPINFO structure.)

If you want to pass this information to the process being launched, you'll have to come up with your own mechanism for transferring this information. For example, you can pass it on the command line, or if you have a lot of information to pass, you can use a shared memory block.

Comments (10)
  1. Michael Mol says:

    Command line, shared memory, named pipe…there are a lot of IPC mechanisms available.

    For kicks, I once pondered setting up 9 named events to simulate an 8-bit parallel line plus clock. The bits would be non-auto-reset, and the clock line would be auto-reset. I never did do it, though.

  2. Darkstar says:

    This should be known to anyone who ever tried to program his own screensaver. The Win95-like preview in the small "monitor" icon uses the same mechanism (it passes something like "/h:<handle>" to the .scr file)

  3. Archer says:

    I think that passing pid might be better than handle of the parent process, because if the child process does not inherit the handles of its parent, the passed handle would be invaild. You can get a handle of a process by pid at any time. Is that right?

  4. Alexandre Grigoriev says:


    Window handles are desktop-global. They are not "inherited" like kernel object handles.

  5. Anonymous says:


    One problem with using process IDs is: What happens if the parent process dies?  Either intentionally or due to a crash.  Suddenly then, depending on timing, you could potentially have a process ID that refers to a completely unrelated process, since these IDs can generally be reclaimed.

  6. Spire says:

    Another problem with using process IDs for this purpose is that processes can have more than one window.

  7. Richard Russell says:

    There's a useful list of IPC mechanisms at…/aa365574.aspx

  8. Archer says:

    @Alexandre Grigoriev:

    Oh, I omitted that it is Windows Handle, not Process Handle. Thanks.

  9. Joe says:

    just implement and register a singleton COM object in the EXE you've launched.  after you launched it, Call CoCreateInstance and then you can pass whatever information you want via whatever interface you want.  that is why COM was created!!

  10. 640k says:


    Windows handles are also reused.

    Suddenly then, depending on timing, you could potentially have a windws handle that refers to a completely different window, since these HWNDs can generally be reclaimed.

Comments are closed.

Skip to main content