MacType crashes vscode randomly with oridinal 345 DLL error

[chawyehsu]

MacType Info:

Windows 7 Service Pack 1
Resolution: 1920 x 1080
MacType version:    1.2018.1019.0
MacTray version:    1.0.5.2116

vscode info:

Version: 1.30.0
Commit: c6e592b2b5770e40a98cb9c2715a8ef89aec3d74
Date: 2018-12-11T22:29:11.253Z
Electron: 2.0.12
Chrome: 61.0.3163.100
Node.js: 8.9.3
V8: 6.1.534.41
OS: Windows_NT x64 6.1.7601

vscode main.log:

[2018-12-18 17:27:22.745] [main] [info] update#setState idle
[2018-12-18 17:27:23.979] [main] [error] [VS Code]: render process crashed!
[2018-12-18 17:27:52.827] [main] [info] update#setState checking for updates
[2018-12-18 17:27:53.006] [main] [info] update#setState idle

vscode renderer1.log:

[2018-12-18 17:27:27.174] [renderer1] [error] spawn EPERM: Error: spawn EPERM
    at _errnoException (util.js:1024:11)
    at ChildProcess.spawn (internal/child_process.js:323:11)
    at exports.spawn (child_process.js:514:9)
    at CrashReporter.start (<path_to_vscode>\1.30.0\resources\electron.asar\common\api\crash-reporter.js:57:35)
    at file:///<path_to_vscode>/1.30.0/resources/app/out/vs/workbench/workbench.main.js:2984:412
    at <anonymous>
[2018-12-18 17:27:27.295] [renderer1] [info] no standard startup: not the explorer viewlet
[2018-12-18 17:27:28.915] [renderer1] [error] Cannot read property 'value' of null: TypeError: Cannot read property 'value' of null
    at file:///<path_to_vscode>/1.30.0/resources/app/out/vs/workbench/workbench.main.js:3404:96
    at <anonymous>
    at process._tickCallback (internal/process/next_tick.js:188:7)

P.S. Click Reopen for several times (random), it will have chance to start-up, but vscode will crash again when restarting it. Won't encounter the issue if disable MacType.

[snowie2000]

Hmm, I didn't see any crash on my installation.

And the latest version number should 2018.1 beta5 with DirectWrite (with new tray app) or 1.2018.1205.1 (with old tray app)

[sammilucia]

@h404bi can you please confirm what version of MacTray.exe you have? Is it 1.0.5.3000 or 1.0.5.1?

[chawyehsu]

I have updated MacType to 2018.1 beta5 with DirectWrite, a fresh installation of https://github.com/snowie2000/mactype/releases/tag/2018.1-beta5, and updated VSCode to the latest version 1.30.1. And I still encounter the issue.

But I'm gonna to close this issue, if you guys ask for, since this should be a non-standard usage case I think.

I use MacType with its Standalone loading mode, by a restricted user account, which doesn't have admin privileges. Since the account doesn't have permission to execute the MacType installer, I copied the whole MacType folder from another PC, and I launched MacTray.exe as normal user. When I decided to change the loading mode from MacType Wizard, It prompted an error Failed to set data for AppInit_DLLs, the same as #103 , when I clicked Finish, whatever mode I chose. But if I click it twice, it wouldn't prompt the error again, until the next time I open up MacType Wizard.

On the other side, If I launch VSCode while MacType is running, mostly it will prompt "The ordinal 345 could not be located in dinamyc link library COMCTL32.dll", then sometimes show the aforementioned crash dialog.

I didn't encounter this issue before. And now everything else works as expected, except for VSCode.

But everything is fine on my another PC with an admin account, the same MacType version, the same VSCode version.

Though it's a non-standard usage case I think, I want to figure it out that why only VSCode suffers.

[sammilucia]

@h404bi can you please right-click on MacType.exe > select Properties > Details, and tell me which version it is?

[chawyehsu]

@sammilucia It's 1.0.5.1 now, I have deleted the old version, and updated to the latest one.

MacType version:    2018.1 beta 5 with DirectWrite
MacTray version:    1.0.5.1

[sammilucia]

Thanks @h404bi ... I do believe that's the latest one (and actually newer than 1.0.5.3000) - @snowie2000 still waiting for you to confirm...

[snowie2000]

I checked the export table of COMCTL32.dll and confirmed that the ordinal#345 is TaskDialogIndirect (MSDN). MacType definitely doesn't use it.

Since this API existed long back to vista era, I don't think vs code is loading the wrong file since there is no wrong file to load in modern Windows.

Anyway, could you please use Process Explorer on the crash process to verify that which COMCTL32.DLL file is vs code trying to load? That may make the real problem clear.

[chawyehsu]

@snowie2000 When VSCode alerts The ordinal 345 could not be located in dinamyc link library COMCTL32.dll:

When VSCode shows crash dialog:

When VSCode correctly start-up:

Besides, MacType's comctl32.dll:

[snowie2000]

It's not the parent VSCode.exe that crashed, it's the child VSCode.exe. You should rather check those ones'.

[chawyehsu]

@snowie2000 I can't catch that, since the child process died too fast. And Process Explorer will point to the parent process if I use Find Process.

[snowie2000]

You should be able to catch it when Windows alerts you about not able to find the ordinal 345. The process will be stuck at startup and the DLL is already loaded at I demonstrated below.

[chawyehsu]

The first screenshot I provided above is the result when it alerts ordinal 345 could not be located. Just have one Code.exe process, no child processes. It loaded C:\Windows\System32\comctl32.dll.

[snowie2000]

Could you please upload the file so we can have a close examination of it

[chawyehsu]

@snowie2000 Did you mean the C:\Windows\System32\comctl32.dll file? comctl32.zip

[snowie2000]

The oridinal 345 doesn't exist in the dll. So the vsCode does load the wrong file, we just don't know why...

[chawyehsu]

So now it's more clear, vscode would have chance to load a wrong comctl32.dll (an old version of comctl32.dll without oridinal 345), if I launch it when MacType is running. But we don't know why it did the wrong thing.

[snowie2000]

In theory, the side by side mechanism will load the correct dlls for an application even when there is a dll with the same filename loaded. So, even if MacType loaded the wrong dll before vscode did, Windows should load another version of this dll for vscode.exe. Although... MacType can't be loaded before any .exe.

[chawyehsu]

I found that the oridinal 345 error still occur even if I added Code.exe into [UnloadDll] and [ExcludeSub] list. But if I disabled MacType from MacTray, the oridinal 345 error won't appear anymore. I have tested it for many times...

[snowie2000]

Which loading mode are you using?

[chawyehsu]

Standalone loading mode.

MacType.ini:

[MacType]
RedrawDelay=5000
AutoEnable=1
HideDenied=1
AutoUnload=1
AutoRun=0
LoadType=1
Use64Agent=1
HideACD=1
Language=2

[snowie2000]

That is extremely weird. Because when the parent process launching the child process, it checks the process name in the unload list, if it is included, nothing will be modified for this child process. When MacTray.exe detects a new process, it checks for the unload list too and does nothing if it is in the list.

Could you please check all the loaded dlls of the "unloaded" vsCode.exe to see if there is any MacType related dlls being loaded?

[chawyehsu]

None of MacType related DLLs being loaded.

But there is a strange behavior shown in the processes loading status window of MacType, the process name of Code.exe is missing and the status of the process is Disabled instead of Ignore(Disabled).

[snowie2000]

The process capturing logic is changed in the new version of the tray app. Sometimes it just says Disabled which is totally normal.

I've experienced this strange behavior before and still have no idea why the process name can't be captured. Maybe it could potentially cause some trouble?

[chawyehsu]

I've got a new machine and there is no way to repoduce the issue, so I'm gonna close this.

[mfreeman-xtivia]

This item is pretty much reproducible on demand for me now. It appears to be something unholy going on between Electron apps and the latest MacType. In particular if I try to start VS Code i will see this error probably 8 times out of 10.

Even more interesting is that i wasn't really seeing this at all, did a Windows update to pull in the the 2019-08 update pack for Windows, and now it pretty much happens ALL the time. :-(

[mfreeman-xtivia]

FWIW there is definitely some correlation with Electron apps and this problem. Now see it happening with Slack and other Electron-based apps. Its also random in that about half the time it doesn't occur.

Could there be some kind of timing issue when DLL injection/replacement is occuring during the Electron app startup?

[sammilucia]

For the missing Process name @snowie2000 this may help https://superuser.com/questions/1193751/what-is-non-existent-process-in-windows

[mfreeman-xtivia]

No idea why, or even whether its a false signal, but switching from Service mode to Registry mode seems to have made the problem go away

[wmjordan]

@mfreeman-xtivia

You assumption that this issue had something to do with Electron might not be correct. I also met with this issue occasionally, but not only on VSCode.

One of the affected application was Postman, a Web API debugging tool, which was an Electron based application. The other one was BowPad, which was a single process, standalone application without using Electron or other host.

MacType was running in Service Mode when the crash occurred.

[snowie2000]

I was also using postman for network debugging, and it's so far so good. Maybe it's because I'm still using the old-fashioned Windows 7?

[wmjordan]

I checked out the Windows Event Logs on my computer for the recent 12 months (no more, older entries might have been erased) and found quite a brunch of applications:

Postman.exe (version 7.27, 7.26, Electron based, each version once, I'd just been using it for two months or so) Code.exe (VS Code, Electron based, about 3 times, I did not launch it often, about once or twice per month only) draw.io.exe (this one was based on Electron either?) BowPad.exe (a traditional application, crashed more than 10 times, well I used this application daily) TortoiseProc.exe (this is a traditional application as well, nothing to do with Electron at all)

[wmjordan]

Maybe it's because I'm still using the old-fashioned Windows 7?

I've been using Windows 10 for quite a few years. But @chawyehsu was using Windows 7 SP1 as well when he posted this issue.

[snowie2000]

I think it's something to do with the Windows side by side. Maybe MacType somehow misdirected Windows for the path of manifests? I'm still not quite clear about the principle of the Windows SxS.

[wmjordan]

It seemed to had something to do with the Windows side by side.

I ransacked my system drive and found quite a good scores of comctl32.dll, the suspect in the above discussion. I did not computer file hash codes. There are at least four kinds of comctl32.dll files in my system, size at 557KB, 659KB, 2099KB and 2515KB respectively.

The two smaller ones (located at SysWOW64 and System32) do not have ordinal 345; the larger two in the SxS directories do have ordinal 345.

It is quite strange that only oridinal 345 has been reported to be missing, but not other functions.

[snowie2000]

Windows side by side determines which version of the dll should be used for a certain executable. It mainly depends on the application's manifest (standalone file or embedded). But what if there is no manifest? I don't know.

[wmjordan]

I checked the manifest of the five victims of this issue in my system.

Each of them has a manifest to specify comctl32.dll version 6 by the following line:

<assemblyIdentity type="win32" name="Microsoft.Windows.Common-Controls" version="6.0.0.0" 
   processorArchitecture="*" publicKeyToken="6595b64144ccf1df" language="*">

[snowie2000]

Could this issue be caused by some other applications, since Snowie said she did not use TaskDialogIndirect, the function with an ordinal of 345?

@chawyehsu @mfreeman-xtivia Do you use Classic Shell or some other system wide components hooking the shell?

The meaning of windows side by side is to solve the infamous Dll hell. There are different versions of the same dll located in the WinSxs folders, some of them are old versions with some APIs missing (but may with extra old obsolete APIs that old applications may rely on. So the problem is that the Windows side by side didn't load the correct version for VSCode. It loaded an old version which lacks the API ordinal 345. That's the reason you saw this error dialog.

[wmjordan]

I put my eyes on other system-wide applications besides MacType, and checked what DLLs BowPad had loaded with Process Explorer, since this application had the least dependency in the above five victims.

Afterward, I found the following libraries EasyHK64.dll, ListaryHook64.dll in suspect. I checked the DLL dependencies of the above two files and found that EasyHK64 did not use comctl32, but ListaryHook64 did.

Moreover, ListaryHook64 did not specified the version of comctl32. Its manifest was:

<?xml version='1.0' encoding='UTF-8' standalone='yes'?>
<assembly xmlns='urn:schemas-microsoft-com:asm.v1' manifestVersion='1.0'>
  <trustInfo xmlns="urn:schemas-microsoft-com:asm.v3">
    <security>
      <requestedPrivileges>
        <requestedExecutionLevel level='asInvoker' uiAccess='false' />
      </requestedPrivileges>
    </security>
  </trustInfo>
</assembly>

Could ListaryHook64 be the cause of the problem (comctl32 version 5 being loaded instead of version 6) but not MacType?

[wmjordan]

Today, this issue recurred. I used Process Explorer to examine the loaded DLLs in the problematic process and got the following result.

From the above screenshot: The process had loaded the old version of comctl32.dll. No third-party DLL had ever been injected/loaded to the process when this error occurred.

[snowie2000]

Hi, I would like to see if there is any volunteer to give the new bootstrap a try. LrdLoadDll hook has been removed in this build and I believe this is most likely the cause of the Sxs problem. MacType64.zip

[wmjordan]

Thank you for looking into this issue. I bought a new computer about 3 weeks ago (OS became Win10 1909) and did not met with this issue yet.

I've just downloaded the new dll and let's see whether this issue reoccurs.

[wmjordan]

My Windows Event Log got erased on 24th, Nov accidentally. :( I could not remember what happened before that. According to the remaining logs, I did not met with this issue after that.

However, I got an error like that a week ago. I did not realize the crash was about EasyHk. I will try to make a minidump next time if it reoccurs.

错误应用程序名称: HaoZip.exe，版本: 6.2.0.11032，时间戳: 0x5f475d26 错误模块名称: Easyhk64.dll，版本: 2.7.0.1，时间戳: 0x5ce213db 异常代码: 0xc0000005 错误偏移量: 0x000000000001c83f 错误进程 ID: 0x3f30 错误应用程序启动时间: 0x01d6cfb88b6453aa 错误应用程序路径: C:\Program Files (x86)\HaoZip\HaoZip.exe 错误模块路径: C:\Program Files\MacType\Easyhk64.dll 报告 ID: 91a90447-6f93-497b-b7cf-ad6e673a2105 错误程序包全名: 错误程序包相对应用程序 ID:

[MintMana]

@snowie2000 Thanks for your work very much. I recieve the error msg of "oridinal 345" every time when electron apps like terminus and typora launch for the first time and suspect that slack's random crash is caused by Mactype. For me, this error is definitely reproduceable as long as the system is rebooted. However, VScode never crashes.

After using your latest build here, the same error msg still show up. The error msg goes away if Mactype is not loaded automatically and show up once Mactype is loaded at least in Service Mode.

The OS is Windows 10 20H2 with the latest patch. Feel free to let me know if you need additional information.