Hi,
Our customers report us they often has applicaiton freeze.
When I analyse dump file, there everywhere the similar problem with
win32u.dll!NtUserMsgWaitForMultipleObjectsEx() Unknown Non-user code. Symbols loaded.
And backgroundworker threads
ntdll.dll!NtWaitForMultipleObjects() Unknown Non-user code. Symbols loaded.
KERNELBASE.dll!WaitForMultipleObjectsEx() Unknown Non-user code. Symbols loaded.
[Managed to Native Transition] Annotated Frame
mscorlib.dll!System.Threading.WaitHandle.WaitAny(System.Threading.WaitHandle[] waitHandles, int millisecondsTimeout, bool exitContext) Line 454 C# Symbols loaded.
DevExpress.RichEdit.v18.2.Core.dll!DevExpress.XtraRichEdit.Layout.Engine.BackgroundFormatter.WorkerBody(System.WeakReference thisWeakRef = {System.WeakReference}) Unknown No symbols loaded.
DevExpress.RichEdit.v18.2.Core.dll!DevExpress.XtraRichEdit.Layout.Engine.BackgroundFormatter.Worker(object parameter) Unknown No symbols loaded.
mscorlib.dll!System.Threading.ExecutionContext.RunInternal(System.Threading.ExecutionContext executionContext, System.Threading.ContextCallback callback, object state, bool preserveSyncCtx) Line 954 C# Symbols loaded.
mscorlib.dll!System.Threading.ExecutionContext.Run(System.Threading.ExecutionContext executionContext, System.Threading.ContextCallback callback, object state, bool preserveSyncCtx) Line 902 C# Symbols loaded.
mscorlib.dll!System.Threading.ExecutionContext.Run(System.Threading.ExecutionContext executionContext, System.Threading.ContextCallback callback, object state) Line 891 C# Symbols loaded.
mscorlib.dll!System.Threading.ThreadHelper.ThreadStart(object obj) Line 93 C# Symbols loaded.
[Native to Managed Transition] Annotated Frame
kernel32.dll!BaseThreadInitThunk() Unknown Non-user code. Symbols loaded.
> ntdll.dll!RtlUserThreadStart() Unknown Non-user code. Symbols loaded.
Is it possible the DevExpress RIchEdit component produce the freeze?
Hi,
It is difficult to determine the cause of the issue based on this call stack only. Would you please clarify if the RichEditControl freezes with a specific document? If so, send us this document for research.
It will be helpful if you provide us with a small sample that replicates the problem. We will test it locally.
Hello Yulia,
We have this report from different customers, so, for us its not possible to reproduce it.
Then we begin to collect dump files from customers and analyse it.
I could share the last one Dump file, but this is 450Mb. How can I do that?
You may upload this dump to our FTP server. To access the FTP server, use the following credentials:
Server: ftp.devexpress.com
User: UPLOAD
Password: HEREYOUARE
However, I am not sure if we are able to determine the cause of the issue based on a dump file (without the problematic document).
I recommend you check if there are any handled exceptions when RichEditControl freezes. If it is not possible to attach a debugger to the application to obtain the call stack, you can handle the AppDomain.FirstChanceException event and save the exception's call stack programmatically. Please refer to the How to obtain the exception's call stack article for clarification.
Hi,
We also have a problem to catch this problem, because this happens by diffrent customers and we found nothing similar between them, only in the dump file thread stack shows always the RichEditControl Layout background worker. But I still not sure this is a real problem for freeze… I just made this conclusion.
I upload the dump file. The filename is GoliathNet64.zip.
Would be nice if it help.
Thanks
Hi Dennis,
Usually, in such situations, the cause of this issue is the same - an event handler subscribes to the SystemEvents.OnUserPreferenceChanged event in a non UI thread before an event handler subscribes to this event in an UI thread. As a result, an incorrect synchronization context is captured. This behavior can take place, for instance, if any DevExpress control is created in a non UI thread.
See the App Hang OnUserPreferenceChanged and UI not responding after a few minutes after maximizing tickets for clarification.
Please send us a small sample that demonstrates how our RichEditControl is created in your real application.
Hello Yulia,
I thinking the samples does not helps… because RTF control using in many scenarios in the application, and difficult to say which one bring the freeze. Does my dump file help to understand some source of the problem? When not, maybe you can suggest the way to track OnUserPreferenceChanged event. Is it possible to log which controls from which thread subscribe it ? Then probably could be found place in the application which using Rtf or other GUI controls in separate thread.
Thanks
Denis
Hello Denis,
Our default UserLookAndFeel object subscribes to the Microsoft.Win32.SystemEvents.UserPreferenceChanged event when the first StyleChanged event handler is created. So, if the first UI control is created in a background thread, subscription to the Microsoft.Win32.SystemEvents.UserPreferenceChanged event is performed in a background thread. This may lead to the application hanging if User Preferences change when the form is alive.
class UserLookAndFeelDefault : UserLookAndFeel protected override void OnFirstSubscribe() { Microsoft.Win32.SystemEvents.UserPreferenceChanged += new Microsoft.Win32.UserPreferenceChangedEventHandler(OnUserPreferencesChanged); }
You may add a breakpoint into the OnFirstSubscribe method of the UserLookAndFeelDefault class and check from which thread this method is called.
See also: How can I debug DevExpress .NET source code using PDB files
Please keep us informed of your results.
I also recommend you review the Initialization of RichEdit and its Ribbons very slow ticket where the issue with the Microsoft.Win32.SystemEvents.UserPreferenceChanged event was researched.