none
Process.Start causes processing of Windows Messages RRS feed

  • Question

  • Hi,

    I got a strange exception in my application (FW 3.5): I have an exception handler in Sub Main that, among other actions like writing a log file, calls Process.Start to open the log file in the default editor.

    The problem is, during Process.Start, OnMouseMove of the already shown Form is executed. This leads to another exception because, at this point in time, some initializations haven't been done yet. So, why does Process.Start cause OnMouseMove? This is the stack trace:

     	UnitTest.exe!UnitTest.MainView.OnMouseMove(System.Windows.Forms.MouseEventArgs)	Basic
     	System.Windows.Forms.dll!System.Windows.Forms.Control.WmMouseMove(ref System.Windows.Forms.Message)	
     	System.Windows.Forms.dll!System.Windows.Forms.Control.WndProc(ref System.Windows.Forms.Message)	
     	System.Windows.Forms.dll!System.Windows.Forms.Control.ControlNativeWindow.OnMessage(ref System.Windows.Forms.Message)	
     	System.Windows.Forms.dll!System.Windows.Forms.Control.ControlNativeWindow.WndProc(ref System.Windows.Forms.Message)	
     	System.Windows.Forms.dll!System.Windows.Forms.NativeWindow.Callback(System.IntPtr, int, System.IntPtr, System.IntPtr)	
     	[transition from native to managed]
     	[transition from managed to native]	
    >	System.dll!System.Diagnostics.ShellExecuteHelper.ShellExecuteFunction()	
     	System.dll!System.Diagnostics.ShellExecuteHelper.ShellExecuteOnSTAThread()	
     	System.dll!System.Diagnostics.Process.StartWithShellExecuteEx(System.Diagnostics.ProcessStartInfo)	
     	System.dll!System.Diagnostics.Process.Start()	
     	System.dll!System.Diagnostics.Process.Start(System.Diagnostics.ProcessStartInfo)	
     	System.dll!System.Diagnostics.Process.Start(string)	
     	UnitTest.exe!UnitTest.Main.HandleException(System.Exception)	Basic
     	UnitTest.exe!UnitTest.Main.Main()	Basic
    

    As you can see, there's a native<->managed transition. That block expanded looks like this:

     	[transition from native to managed]	
     	user32.dll!_InternalCallWinProc@20() 	
     	user32.dll!_UserCallWinProcCheckWow@32() 	
     	user32.dll!_DispatchMessageWorker@8() 	
     	user32.dll!_DispatchMessageW@4() 	
     	shell32.dll!_SHProcessMessagesUntilEventsEx@20() 	
     	shell32.dll!CShellExecute::_RunThread() 	
     	shell32.dll!CShellExecute::ExecuteNormal() 	
     	shell32.dll!ShellExecuteNormal() 	
     	shell32.dll!_ShellExecuteExW@4() 	
     	[transition from managed to native]	
    
    Obviously, there's a call to _SHProcessMessagesUntilEventsEx that causes this - but why? This can cause unpredictable results because I do not expect my own application to continue by a call to Process.Start.

    Armin

    Friday, November 9, 2012 11:53 AM

Answers

  • ShellExecuteEx may pump window messages when opening a document in its associated application, specifically in the case where a DDE conversation is specified in the file association.

    Additionally, ShellExecuteEx may create a separate thread to do the heavy lifting. Depending on the flags specified in the SHELLEXECUTEINFO structure, the ShellExecuteEx call may not return until the separate thread completes its work. In this case, ShellExecuteEx will pump window messages to prevent windows owned by the calling thread from appearing hung.

    You can either ensure that the variables in question are initialized prior to calling Process.Start, move the Process.Start call to a separate thread, or call ShellExecuteEx directly with the SEE_MASK_ASYNCOK flag set.


    Dave Anderson - Microsoft
    Please remember click "Mark As Answer" on the replies that help.

    Tuesday, November 13, 2012 8:10 PM

All replies

  • Hi Armin.

    Thank you for posting on this forum.

    I am trying to involve some other one into this thread.

    Please wait it patiently.

    Thank you.

    Best regards,


    Mike Feng
    MSDN Community Support | Feedback to us
    Please remember to mark the replies as answers if they help and unmark them if they provide no help.

    Monday, November 12, 2012 6:53 AM
    Moderator
  • ShellExecuteEx may pump window messages when opening a document in its associated application, specifically in the case where a DDE conversation is specified in the file association.

    Additionally, ShellExecuteEx may create a separate thread to do the heavy lifting. Depending on the flags specified in the SHELLEXECUTEINFO structure, the ShellExecuteEx call may not return until the separate thread completes its work. In this case, ShellExecuteEx will pump window messages to prevent windows owned by the calling thread from appearing hung.

    You can either ensure that the variables in question are initialized prior to calling Process.Start, move the Process.Start call to a separate thread, or call ShellExecuteEx directly with the SEE_MASK_ASYNCOK flag set.


    Dave Anderson - Microsoft
    Please remember click "Mark As Answer" on the replies that help.

    Tuesday, November 13, 2012 8:10 PM
  • Thanks Dave for your reply and the valuable information. I'll call Process.Start in a different thread. Thanks.

    Armin

    Friday, November 16, 2012 12:04 PM