Intermittent full UI freeze in Maxthon 7.5.3.2000 on Windows 10

Mark

I am experiencing intermittent complete freezes of Maxthon 7.5.3.2000 on Windows 10 x64.
The browser UI becomes completely unresponsive and must be force-closed. The issue is difficult to reproduce consistently and does not occur in other browsers on the same system.

I captured a full memory dump during a real freeze using ProcDump with the -ma -h options and analyzed it with WinDbg.

WinDbg reports an application hang involving a contended/orphaned critical section inside chrome.dll. The main browser thread (CrBrowserMain) is blocked in:

ntdll!RtlpWaitOnCriticalSection
ntdll!RtlpEnterCriticalSectionContended
ntdll!RtlEnterCriticalSection

Immediately below that, the stack enters Maxthon-specific code:

chrome!maxthon::rest_service::MxRestServiceManager::CreateMxRestService

chrome!maxthon::rest_service::MxRestServiceManager:😮nServerStarted

The WinDbg hang analysis also reports:

APPLICATION_HANG_Orphaned_CriticalSection

In addition, the Chrome_IOThread was blocked in WriteFile, with the stack also passing through:

MxRestServiceManager::CreateMxRestService

MxRestServiceManager::GetMxRestServiceAddress

This suggests the freeze may be related to an internal synchronization/deadlock issue in Maxthon's REST service subsystem rather than a webpage renderer or GPU failure.

The freeze occurred during normal browsing. In the captured case, it happened while visiting waterfox.com/download/, but the issue is intermittent and not obviously tied to that site specifically.

Additional information:

Maxthon version: 7.5.3.2000
OS: Windows 10 x64, build 19045
Other browsers on the same machine do not show this issue
ProcDump confirmed a hung window and successfully captured the dump

I can provide the WinDbg text output and, if needed, the full memory dump.

Abdullah57

Mark That's some proper debugging work. The orphaned critical section in MxRestServiceManager::CreateMxRestService is a strong lead—sounds like a race condition when the REST service starts up.

Not much you can fix on your end though. This needs Maxthon devs to patch the synchronization logic. I'd open a ticket and attach the WinDbg output—they'll need it since it's hard to reproduce.

In the meantime, maybe try disabling any Maxthon sync/cloud features in settings. If the REST service is tied to that, it might reduce how often it hangs.

Good luck. Hope they actually look at it.

Mark

I have the complete WinDbg output (!analyze -v and ~* k) and the original full memory dump. I can provide them privately to the developers if required.

report-maxthon.txt

59kB

Stefan5

Hey Mark,

Solid debugging — that's not something most users would dig into. The orphaned critical section in MxRestServiceManager::CreateMxRestService really does point to a race condition on service startup.

Abdullah57's advice is spot on. Since it's internal Maxthon code, there's nothing you can patch yourself. Best bet is opening a ticket with the dump attached — devs can't ignore a proper WinDbg analysis.

In the meantime, disabling sync/cloud features might reduce the frequency, like he said. Worth testing.

One other thing — do you have any extensions or third-party tools interacting with Maxthon's REST layer? Sometimes those can trigger timing issues that wouldn't happen on a clean install.

Hope the devs actually look at it. This is a real bug, not user error.

driveforce

I have the complete WinDbg output, including !analyze -v and ~* k, along with the original full memory dump. I can provide these files privately to the developers if they need them for further investigation. The dump and debugging output should provide useful information for identifying the cause of the crash and investigating any related driver or system issues.