i'm using the Win32 progress dialog. The damnest thing is that when i call: progressDialog.StopProgressDialog(); it doesn't disappear. It stays on screen until the user moves her mouse over it - then it suddenly disappers. The call to StopProgressDialog returns right away (i.e. it's not a synchronous call). i can prove this by doing things after the call has returned: private void button1_Click(object sender, EventArgs e) { //Force red background to prove we've started this.BackColor = Color.Red; this.Refresh(); //Start a progress dialog IProgressDialog pd = (IProgressDialog)new ProgressDialog(); pd.StartProgressDialog(this.Handle, null, PROGDLG.Normal, IntPtr.Zero); //The long running operation System.Threading.Thread.Sleep(10000); //Stop the progress dialog pd.SetLine(1, "Stopping Progress Dialog", false, IntPtr.Zero); pd.StopProgressDialog(); pd = null; //Return form to normal color to prove we've stopped. this.BackColor = SystemColors.Control; this.Refresh(); } The form: starts gray turns red to show we've stared turns back to gray color to show we've called stop So the call to StopProgressDialog has returned, except the progress dialog is still sitting there, mocking me, showing the message: Stopping Progress Dialog Doesn't Appear for 10 seconds Additionally, the progress dialog does not appear on screen until the System.Threading.Thread.Sleep(10000); ten second sleep is over. Not limited to .NET WinForms The same code also fails in Delphi, which is also an object wrapper around Window's windows: procedure TForm1.Button1Click(Sender: TObject); var pd: IProgressDialog; begin Self.Color := clRed; Self.Repaint; pd := CoProgressDialog.Create; pd.StartProgressDialog(Self.Handle, nil, PROGDLG_NORMAL, nil); Sleep(10000); pd.SetLine(1, StringToOleStr('Stopping Progress Dialog'), False, nil); pd.StopProgressDialog; pd := nil; Self.Color := clBtnFace; Self.Repaint; end; PreserveSig An exception would be thrown if StopProgressDialog was failing. Most of the methods in IProgressDialog, when translated into C# (or into Delphi), use the compiler's automatic mechanism of converting failed COM HRESULTS into a native language exception. In other words the following two signatures will throw an exception if the COM call returned an error HRESULT (i.e. a value less than zero): //C# void StopProgressDialog(); //Delphi procedure StopProgressDialog; safecall; Whereas the following lets you see the HRESULT's and react yourself: //C# [PreserveSig] int StopProgressDialog(); //Delphi function StopProgressDialog: HRESULT; stdcall; HRESULT is a 32-bit value. If the high-bit is set (or the value is negative) it is an error. i am using the former syntax. So if StopProgressDialog is returning an error it will be automatically converted to a language exception. Note: Just for SaG i used the [PreserveSig] syntax, the returned HRESULT is zero; MsgWait? The symptom is similar to what Raymond Chen described once, which has to do with the incorrect use of PeekMessage followed by MsgWaitForMultipleObjects: "Sometimes my program gets stuck and reports one fewer record than it should. I have to jiggle the mouse to get the value to update. After a while longer, it falls two behind, then three..." But that would mean that the failure is in IProgressDialog, since it fails equally well on CLR .NET WinForms and native Win32 code.