Develop Reference

NET 6 COM: An outgoing call cannot be made since the application is dispatching an input-synchronous call

I have a Win11, NET 6.0, Windows App that calls Word through COM to run a Word macro stored inside of the Word instance. All the relevant code has been running for a year or so. I have been debugging for two days without success, reading up on the exception message that I am suddenly getting, trying random code changes, and so on.
My C# program gets the Word instance and tries to run the macro named "FH3" as shown in the code and log trace below. But the code never gets to run the macro because the code that tries to get the Word instance (WordAppGet) fails at runtime. Here are three lines from my log file that show the execution and exception error message.
MacroRun Running Word macro: 'FH3'
WordAppVarsGet GetActiveObject Word.Application failed.
Exception: An outgoing call cannot be made since the application is dispatching an input-synchronous call. (0x8001010D (RPC_E_CANTCALLOUT_ININPUTSYNCCALL))
The following test case code runs okay in Visual Studio.
[TestMethod()]
public void MacroRunTest() {
var me = MethodBase.GetCurrentMethod()?.Name;
MacroRunHelper("FH2", me);
}
// this code has been running fine for many months
public static void
MacroRunHelper(string macroName, string me) {
var msg1 = $"{me} Running Word macro: '{macroName}'";
LogMan.SendNormal(msg1);
var wapp = WordAppGet();
try {
wapp.Run(macroName);
}
catch (Exception ex) {
var msg = $"{me} {ex.Message} '{macroName}'";
LogMan.Send(LogType.Error, msg);
}
}
/// <summary>
/// Get and store a reference to the active Word application.
/// </summary>
public static Word.Application
WordAppGet() {
Word.Application wapp = null;
try {
// Marshal2.GetActiveObject is a copy of the Microsoft reference code
// because it was not included in the MS Interop library when the code was written.
// And GetActiveObject is still not included as of 2022-09-18.
//
// this call fails with the error message
wapp = Marshal2.GetActiveObject("Word.Application") as Application;
}
catch (Exception ex) {
var msg = $"{me} GetActiveObject Word.Application failed.";
LogMessage(PError, msg);
LogMessage(PError, ex.Message);
throw;
}
return wapp;
}
For what it's worth, the online doc about the error message talks a lot about windows controls and BeginInvoke, but this has nothing to do with any Windows controls as far as I can tell.
I have used this same code pattern to access Word, Excel, Outlook, PowerPoint, on NET Framework for a couple of years, and on NET 5 and 6 for more than a year.
It is a mystery to me why it stopped working for Word. It is a mystery to me why it continues to work in the Visual Studio debugger.
Does anyone know how I can fix it to run again? I wonder if any recent Win11 updates have had any changes that break this kind of code. Thank you.

The source of the problem was far away from the code shown above. I switched my top-level WindowsApp from receiving input commands using sockets to receiving using Windows messages. The WndProc branch called some helper code SYNCHRONOUSLY which called other code, and about 10 or 15 calls down the WordAppGet code was called.
Because WndProc calls were synchronous, the WndProc thread was not allowed to "call out" over COM because it might create a deadlock condition. Using Task.Run(...) in the WndProc message branch put the work on a separate thread that was allowed to call out over COM.
Receiving input commands via sockets does not involve the single-thread STA WndProc thread, so sockets worked for a year or more. I was trying to improve the speed of the code and thought Windows messages would be faster. But I wasted more time debugging the COM issue than sockets execution times would have used in 20 years. Bummer.
FWIW, I did not detect the problem until many weeks after I switched from sockets to messages because the COM use case was not tested after the switch.

App.MobileService.LoginAsync fails to show dialog on select machine -> Mind Blown

Just wondering if anyone might be able to point me in the right direction here.
user = await App.MobileService.LoginAsync(provider)
this is the line of code in question. The problem is; this works fine on 2/3 test machines (All Windows 10), the dialog is displayed and the program operates as expected. on the third machine however, the dialog does not display. I have wrapped the function in a try catch block and I am catching all exceptions that I then route to a MessageDialog to display on the screen. the messages are never shown, as though the try succeeded, but the function exits on that line exactly and throws no exceptions. I am using MobileServiceAuthenticationProvider.MicrosoftAccount as my provider.
Code redacted to highlight the error, the full code returns a boolean value for success/failure. All traces past the failing line do not appear, so the function is definitely exiting at the specified line.
try
{
//This line fails on a single machine out of three
user = await App.MobileService.LoginAsync(provider)
}
catch(Exception e)
{
//when it fails, this does not trigger, and no traces after this point
//appear until outside the function
MessageDialog msg = new MessageDialog(e.ToString());
await msg.ShowAsync();
}
and just to make things really weird...message dialogs prior to this point in the code work just fine...
I suspect that the security of the machine in question is blocking the login (windows defender), but I really have no idea where to look for this, or even how to test the problem further. Any ideas as to what would prevent this single machine from displaying the Microsoft login window, or ideas on further debugging would be appreciated.

You are not awaiting the response from the Async reply. This means that you will have an ordering and concurrency issue - sometimes it will work, and sometimes it won't and it's all in the timing.
You need:
var user = await client.LoginAsync(provider);

MSMQ Remote Private: UnsupportedFormatNameOperation after one use

I am new to MSMQ and suspect I either have my queues configured wrong or programmatically (is that a word?)causing them to get hung up.
When everything starts I can send one message and that works wonderfully. I can see (ie via mmc on that machine) the message in the remote machine queue. I then go to access it and I get my UnsupportedFormatNameOperation error. If I try to send another message I get the same error in the send method that just worked a few seconds earlier.
What is even more frustrating is that my catch is NOT picking up the exception so I was unaware and looking elsewhere (read wasting time) till I explored the queue object in the debugger.
Now if I reset the Message Service on remote I lose my message in the queue and still get the same error. If I reboot same result.
On local (dev machine) if I reset the Message Service I still get the error. If I reboot something gets recycled and I can send exactly one message again.
Further after reboot of dev machine and exploring the queue object on the first run I find that I am getting the error the FIRST time around but it still sends the message.
So I am clearly doing something wrong but clueless as to what.
Here is my send code:
private void SendLoginMessage(...bunch of parms)
{
//hardcoded path? yup!!
MessageQueue msmq = new MessageQueue(#"FormatName:DIRECT=OS:W2K8R2_SQL2K8R2\private$\best_simulator");
try
{
LoginStatusMessage LgnMsg = new LoginStatusMessage()
{
...assign parms to my
};
msmq.Send(LgnMsg);
}
catch (MessageQueueException msmqex)
{
MessageBox.Show(msmqex.Message);
}
catch (Exception ex)
{
MessageBox.Show(ex.Message);
}
finally
{
msmq.Close();
}
}

The description for UnsupportedFormatNameOperation is
The requested operation for the specified format name is not supported.
Message Queuing returns this error when the requested operation is not supported for the specified format name. Operations include trying to open a queue to receive messages by specifying a direct format name.
So I guess your problem may be at your receive code.

Checking if a console application is still running using the Process class

I'm making an application that will monitor the state of another process and restart it when it stops responding, exits, or throws an error.
However, I'm having trouble to make it reliably check if the process (Being a C++ Console window) has stopped responding.
My code looks like this:
public void monitorserver()
{
while (true)
{
server.StartInfo = new ProcessStartInfo(textbox_srcdsexe.Text, startstring);
server.Start();
log("server started");
log("Monitor started.");
while (server.Responding)
{
if (server.HasExited)
{
log("server exitted, Restarting.");
break;
}
log("server is running: " + server.Responding.ToString());
Thread.Sleep(1000);
}
log("Server stopped responding, terminating..");
try
{ server.Kill(); }
catch (Exception) { }
}
}
The application I'm monitoring is Valve's Source Dedicated Server, running Garry's Mod, and I'm over stressing the physics engine to simulate it stopping responding.
However, this never triggers the process class recognizing it as 'stopped responding'.
I know there are ways to directly query the source server using their own protocol, but i'd like to keep it simple and universal (So that i can maybe use it for different applications in the future).
Any help appreciated

The Responding property indicates whether the process is running a Windows message loop which isn't hung.
As the documentation states,
If the process does not have a MainWindowHandle, this property returns true.
It is not possible to check whether an arbitrary process is doing an arbitrary thing, as you're trying to.

Process.Kill() related crashes

Or not!
I have a fairly simple application timer program. The program will launch a user selected (from file dialog) executable and then terminate the process after the user specified number of minutes. During testing I found that a crash occurs when I call the Process.Kill() method and the application is minimized to the system tray.
The executable in question is Frap.exe which I use frequently and is the reason I wrote the app timer in the first place. I always minimize fraps to the tray, and this is when the crash occurs.
My use of Kill() is straight forward enough...
while (true)
{
//keep checking if timer expired or app closed externally (ie. by user)
if (dtEndTime <= DateTime.Now || p.HasExited)
{
if (!p.HasExited)
p.Kill();
break;
}
System.Threading.Thread.Sleep(500);
}
In searching for alternatives methods to close an external application programmatically, I found only Close() and Kill() (CloseMainWindow is not helpful to me at all). I tried using Close(), which works providing the application is minimized the tray. If the app is minimized, Close() doesn't cause a crash but the app remains open and active.
One thing I noticed in a few posts posts regarding closing external applications was the comment: "Personally I'd try to find a more graceful way of shutting it down though." made in THIS thread found here at stack flow (no offense to John). Thing is, I ran across comments like that on a few sites, with no attempt at what a graceful or elegant (or crash-free!!) method might be.
Any suggestions?
The crash experienced is not consistant and I've little to offer as to details. I am unable to debug using VS2008 as I get message - cant debug crashing application (or something similar), and depending on what other programs I have running at the time, when the Kill() is called some of them also crash (also programs only running in the tray) so I'm thinking this is some sort of problem specifically related to the system tray.

Is it possible that your code is being executed in a way such that the Kill() statement could sometimes be called twice? In the docs for Process.Kill(), it says that the Kill executes asynchronously. So, when you call Kill(), execution continues on your main thread. Further, the docs state that Kill will throw a Win32Exception if you call it on an app that is already in the process of closing. The docs state that you can use WaitForExit() to wait for the process to exit. What happens if you put a call to WaitForExit() immediately following the call to Kill(). The loop looks ok (with the break statement). Is it possible that you have code entering that loop twice?
If that's not the problem, maybe there is another way to catch that exception:
Try hooking the AppDomain.CurrentDomain.UnhandledException event
(currentDomain is a static member)
The problem is that Kill runs asynchronously, so if it's throwing an exception, it's occurring on a different thread. That's why your exception handler doesn't catch it. Further (I think) that an unhandled async exception (which is what I believe you have) will cause an immediate unload of your application (which is what is happening).
Edit: Example code for hooking the UnhandledExceptionEvent
Here is a simple console application that demonstrates the use of AppDomain.UnhandledException:
using System;
public class MyClass
{
public static void Main()
{
System.AppDomain.CurrentDomain.UnhandledException += MyExceptionHandler;
System.Threading.ThreadPool.QueueUserWorkItem(DoWork);
Console.ReadLine();
}
private static void DoWork(object state)
{
throw new ApplicationException("Test");
}
private static void MyExceptionHandler(object sender, System.UnhandledExceptionEventArgs e)
{
// get the message
System.Exception exception = e.ExceptionObject as System.Exception;
Console.WriteLine("Unhandled Exception Detected");
if(exception != null)
Console.WriteLine("Message: {0}", exception.Message);
// for this console app, hold the window open until I press enter
Console.ReadLine();
}
}

My first thought is to put a try/catch block around the Kill() call and log the exception you get, if there is one. It might give you a clue what's wrong. Something like:
try
{
if(!p.HasExited)
{
p.Kill();
}
break;
}
catch(Exception ex)
{
System.Diagnostics.Trace.WriteLine(String.Format("Could not kill process {0}, exception {1}", p.ToString(), ex.ToString()));
}

I dont think I should claim this to be "THE ANSWER" but its a decent 'work around'. Adding the following to lines of code...
p.WaitForInputIdle(10000);
am.hWnd = p.MainWindowHandle;
...stopped the crashing issue. These lines were placed immediately after the Process.Start() statement. Both lines are required and in using them I opened the door to a few other questions that I will be investigating over the next few days. The first line is just an up-to 10 second wait for the started process to go 'idle' (ie. finish starting). am.hWnd is a property in my AppManagement class of type IntPtr and this is the only usage of both sides of the assignment. For lack of better explaination, these two lines are analguous to a debouncing method.
I modified the while loop only slightly to allow for a call to CloseMainWindow() which seems to be the better route to take - though if it fails I then Kill() the app:
while (true)
{
//keep checking if timer expired or app closed externally (ie. by user)
if (dtEndTime <= DateTime.Now || p.HasExited) {
try {
if (!p.HasExited) // if the app hasn't already exitted...
{
if (!p.CloseMainWindow()) // did message get sent?
{
if (!p.HasExited) //has app closed yet?
{
p.Kill(); // force app to exit
p.WaitForExit(2000); // a few moments for app to shut down
}
}
p.Close(); // free resources
}
}
catch { // blah blah }
break;
}
System.Threading.Thread.Sleep(500);
}
My initial intention for getting the MainWindowHandle was to maximize/restore an app if minimized and I might implement that in the near future. I decided to see if other programs that run like Fraps (ie, a UI but mostly run in the system tray (like messanger services such as Yahoo et al.)). I tested with XFire and nothing I could do would return a value for the MainWindowHandle. Anyways, this is a serperate issue but one I found interesting.
PS. A bit of credit to JMarsch as it was his suggestion RE: Win32Exception that actually lead me to finding this work around - as unlikely as it seems it true.