UWP apps app gets killed due to moapplication_hang_cffffff hang_activation or hang_quiesce from timeout of combase.dll calling NtWaitForMultipleObjects() with infinite timeout

Question

Hi,

Our top UWP app's top health issue in our dashboard is shown as: moapplication_hang_cffffff hang_activation or hang_quiesce

All the stack traces are in kernel code and/or comm dll such as the following below.

Can you please tell more details on how to avoid this type of issue or please fix the code in Windows so it no longer occurs.

Our level code definitely doesn't own working with NtWaitForMultipleObjects. It looks like combase.dll is not giving the correct timeout.

Br, Karhu.

ntdll.dll!NtWaitForMultipleObjects ()   
KERNELBASE.dll!00007ffe7d788910()   
combase.dll!MTAThreadWaitForCall(CSyncClientCall * pClientCall=0x0000018726719c60, WaitForCallReason reason=0x26780240, unsigned long dwRetryTimeout=0xffffffff) Line 7234  C++ Symbols loaded.
combase.dll!MTAThreadDispatchCrossApartmentCall(tagRPCOLEMESSAGE * pMessage=0x00000015944fcf20, OXIDEntry * pOXIDEntry=0x000001870aa5bf90, CSyncClientCall * pClientCall=0x0000018726719c60) Line 229   C++ Symbols loaded.

Answer 1

Correct @RoyLi-MSFT , the app is not directly calling NtWaitForMultipleObjects, we just see it on the stack listing as shown above for the cause of terminations

Well, if we let the app run for a day or two (NOT under the debugger, since the environment behaves differently, but as a user would do), the app does quit from one of the moapplication_hang_cffffff hang_activation or hang_quiesce terminations.

RoyLi, could you please explain more about moapplication_hang_cffffff hang_activation or hang_quiesce terminations ?

Why and when is the OS making these forced terminations?

I don't think the App Center diagnostic monitoring will help in the case where something more low-level is causing the "hang and termination."

Perhaps someone at Microsoft can run the app under the kernel debugger and break on when the termination is happening to see what the cause of the issue/termination is ?

Answer 2

Hello,

Welcome to Microsoft Q&A!

After discussed with other engineers, we found it is not suitable to discuss via the forum. It needs more professional support. I suggest that you might need to open a support ticket for this: Developer Tools->Windows UWP Development->Windows 10 Universal App Dev. Please contact our paid phone support at MS Support. You will get 1:1 support on that. Please kindly note that your support ticket will be free if it is Microsoft's issue.

Thank you.

Answer 3

Hi @KarhuKoti-5578 ,

I’ve collected some information that can help provide more detail on this and give some insight on ways to troubleshoot errors like these.

As you’ve already mentioned, the “moapplication_hang_cffffff”, “hang_activation” or “hang_quiesce” errors are indeed too low-level to extract meaningful information out of. These particular errors could be occurring due to a wide variety of issues, and unexpected behaviors in managed code could propagate and only manifest themselves as these errors we are seeing being logged in the dashboard. It can be difficult to say exactly why these errors are being thrown using only the stacktrace and errors logged.

Sometimes when the stack trace includes ‘NtWaitForMultipleObjects’ or ‘MTAThreadWaitForCall’ from Combase, it can be due to issues occurring with long running tasks, async/threading issues or issues with invoking calls on the main UI thread. A potential example would be if a long running task has started and is expected to run in the background, however if it crashes, the detailed error might not be sent back to the main calling thread as the long running task either lost the context of the calling thread or fatally crashes before it was able to propagate the error back to the managed code. The methods seen in the stacktrace (such as NtWaitForMultipleObjects) don’t need to specifically be called from managed code but the lower level code can be indirectly invoked by any number of UWP API’s, frameworks, third-party packages or even general use of async tasks or long running threads. (among other potential unforeseen causes)

These errors could also potentially be caused by a potential bug within the UWP framework. If certain UWP API calls were being made in a way that was unsupported or caused them to crash, it could indicate that this is the unexpected behavior and we would create a bug report to address the issue. However as mentioned earlier, since these errors and stacktrace are too low level, it does not provide enough information to determine where the problem arises from. This may be why there isn’t too much specific documentation on these error messages because the solution to one error will likely not apply to other applications exhibiting the same errors.

Although there can be a few potential areas of investigation that can be taken to troubleshoot this issue. Since the stacktrace mentions ‘NTWaitForMultipleObjects’, it may help to investigate any parts of the managed code that are making any async calls, long running background tasks or calls that are being made directly on the UI thread. (Could be certain background services or specific calls made on UI thread to update the interface with changes or animations.) We have documentation on best practices for managing threading in an application in addition to using the Thread window in Visual Studio to troubleshoot issues. Additionally, the Performance profiler in Visual Studio could provide some information on CPU usage which could indicate areas where the usage is too high or if there is a potential memory issue occurring over a long period of time. (As I understand that this issue can happen after a day or so of running). These are just a few potential areas that can be investigated to see if they are causing the issue. Minimizing the application while still replicating the error can also help in narrowing down areas of interest.

I understand that you mentioned that AppCenter might not be able to capture low level errors. Although indeed there can be instances where the error is originating from the kernel and can be difficult for AppCenter to capture, it could still provide additional information related to the crash should it have initially be caused by something in managed code (that propagated and was thrown as a low-level kernel error). Adding AppCenter logging will allow it to implement global exception handling which can potentially catch the error earlier and returning a detailed stacktrace with more meaningful information to troubleshoot the issue. Additionally, if there are specific areas that you suspect might be contributing to this error, you can create custom logs to be sent to AppCenter in the event of a crash which can allow you to track more precisely where the issue could be occurring in addition to adding general logging throughout the app that can help further.

I do apologize for the inconvenience. As we’ve mentioned before, these error alone do not provide enough information to determine the cause of the problem and resolving issue like these may require additional investigation and logging to gather more details that can help as it can be caused by a wide verity of issues either from managed code or from the UWP framework.

Please let me know if the above information helps in troubleshooting this issue.