I am experiencing a problem with closing a process opened by my Windows Forms application. The problem does not occur on my Windows XP box, but is occurring on my Windows Server 2008 system. The code I am running is:

private Process osk = null; // at the top of the form as a form global variable

osk.StartInfo.FileName = "osk.exe"; // instantiated on form open
osk.Start();

The osk.exe is the windows app On-Screen Keyboard. We are using touch screens, so I needed to provide an input mechanism for configuration editing.

The problem occurs when the form is closed and the following code is executed:

osk.CloseMainWindow();

The exception message is:

"Process has exited, so the requested information is not available."

I moved the close command out of the form closing event, but the app threw the exception anyways. This is a VS 2005 windows form application written in C#.

Ok, one of the guys here gave me the following code that works:

string processName = "osk";
Process[] processes = Process.GetProcessesByName(processName);

foreach (Process process in processes)
{
process.Kill();
}

This terminated the on-screen keyboard without throwing an exception.

Well, I think the problem clearly is that you are trying to issue a command to a process that no longer exists. I suppose that you have the osk Process variable declared at class level, so it retains its value through the lifetime of your form. In this case, I can only assume that the user of the virtual keyboard is closing the keyboard prior to closing your form. So in order to prevent the exception, just use the Process.HasExited property as a condition:


Due to the nature of multitasking, it would still be a good idea to use a try..catch block around calls to osk methods.

---

MCP

I would point out the code is working without a problem under XP. Despite issuing a close command, the process is alive in as much as it remains visible on the screen. I am not closing the on-screen keyboard before the configuration editing is done.

Unfortunately, the coding suggestion you made did not solve the problem. I will, however, use it to handle the condition the user closes the osk prematurely. You are correct about the scope of the osk variable.

I am beginning to suspect it is a permission issue. The calling app does not have sufficient permissions to close the process even though it created it.

Well, in itself, CloseMainWindow() only issues a WM_CLOSE notification to what it considers is the main window of the application. This doesn't require any kind of security to the best of my knowledge.

Still, maybe the Process object is unable to obtain the main window's handle. Experiment with Process.MainWindowHandle. See if it is IntPtr.Zero or -1 (INVALID_HANDLE_VALUE). If it is, then maybe the Process object can't obtain the handle, and therefore can't issue the WM_CLOSE notification. If this is the case, consider terminating the external process instead of playing nice with CloseMainWindow(). Or, see what can be done to resolve the inability of Process to acquire a window handle.

---

MCP

I tried to look at the osk.MainWindowHandle, but the osk HasExited property was already true. So, I put a breakpoint immediately after I launched the osk to allow me to inspect the osk process properties. The process object properties had all thrown exceptions. The HasExited property was set to true as well.

'osk.BasePriority' threw an exception of type 'System.InvalidOperationException'
'osk.MainModule' threw an exception of type 'System.ComponentModel.Win32Exception'

and so on.

Even though the application was successfully launched, the process object does not reflect that. I tried setting the property UseShellExecute to false. This did not help.

Ok, one of the guys here gave me the following code that works:

string processName = "osk";
Process[] processes = Process.GetProcessesByName(processName);

foreach (Process process in processes)
{
process.Kill();
}

This terminated the on-screen keyboard without throwing an exception.