A really strange problem

[sasha]

Hello,
I'm facing a really strange problem when trying to uninstall our product.
It happens on an ARM64 system (MSFT devkit unit), Win 11, fully updated.

This is the command line used to uninstall:
"C:\Windows\System32\msiexec.exe" /x {991977F8-2327-46FD-B74D-CDE068BE3627} /qf

When this command line is launched from our application, it hangs at the 'computing the space requirements' welcome dialog stage.
When the same command is launched from a command prompt (admin level), everything works fine.
The issue doesn't exist on Win10 x64.

I cannot imagine why where we launch the uninstaller from would make a difference.
The log file looks like this: (yes, it just ends abruptly; always the same)

MSI (c) (F4:F0) [14:18:08:884]: Target path resolution complete. Dumping Directory table...
MSI (c) (F4:F0) [14:18:08:884]: Note: target paths subject to change (via custom actions or browsing)
MSI (c) (F4:F0) [14:18:08:884]: Dir (target): Key: TARGETDIR , Object: C:\
MSI (c) (F4:F0) [14:18:08:884]: Dir (target): Key: TempFolder , Object: C:\Users\sasha\AppData\Local\Temp\
MSI (c) (F4:F0) [14:18:08:884]: Dir (target): Key: ProductCode_Dir , Object: C:\Users\sasha\AppData\Local\Temp\{991977F8-2327-46FD-B74D-CDE068BE3627}\
MSI (c) (F4:F0) [14:18:08:884]: Dir (target): Key: SystemFolder , Object: C:\Windows\SysWOW64\
MSI (c) (F4:F0) [14:18:08:884]: Dir (target): Key: System64Folder , Object: C:\Windows\system32\
MSI (c) (F4:F0) [14:18:08:884]: Dir (target): Key: CommonAppDataFolder , Ob

Here is the call stack of the msiexec process.
It basically sits in the ZwWaitLowEventPair +0x1adda8

ntoskrnl.exe!ZwUpdateWnfStateData+0xb2b0
ntoskrnl.exe!KeUpdateThreadTag+0xf554
ntoskrnl.exe!KiDispatchInterrupt+0x7b04
ntoskrnl.exe!KeWaitForMutexObject+0x444
ntoskrnl.exe!KeUpdateThreadTag+0xba14
ntoskrnl.exe!KiDeliverApc+0x18c
ntoskrnl.exe!HalQueryRealTimeClock+0x704
ntoskrnl.exe!KeSynchronizeExecution+0x1388
ntoskrnl.exe!ZwUpdateWnfStateData+0x19bc
msi.dll!QueryInstanceCount+0x358af0
msi.dll!QueryInstanceCount+0x4ff5e0
msi.dll!QueryInstanceCount+0x358af0
msi.dll!QueryInstanceCount+0x4ff5e0
msi.dll!QueryInstanceCount+0x4f85d4
msi.dll!QueryInstanceCount+0x5047d0
msi.dll!QueryInstanceCount+0x483c74
msi.dll!QueryInstanceCount+0x48c608
msi.dll!QueryInstanceCount+0x490828
msi.dll!QueryInstanceCount+0x4a6d98
msi.dll!QueryInstanceCount+0x30f904
msi.dll!QueryInstanceCount+0x33b4c0
msi.dll!QueryInstanceCount+0x4d76f8
msi.dll!QueryInstanceCount+0x3d15e8
msi.dll!QueryInstanceCount+0x3d054c
msi.dll!QueryInstanceCount+0x3e3468
msi.dll!QueryInstanceCount+0x4ef218
msi.dll!QueryInstanceCount+0x3d15e8
msi.dll!QueryInstanceCount+0x3d054c
msi.dll!QueryInstanceCount+0x4040c0
msi.dll!QueryInstanceCount+0x3d9bc0
KERNEL32.DLL!uaw_wcsrchr+0x820f0
ntdll.dll!ZwWaitLowEventPair+0x1adda8

Googling found nothing.

Any idea about this one?

Thanks!

[sasha]

Forgot to mention that eventually there is a message displayed saying 'installer is no longer responding'.

[Catalin]

Hello,

This is quite strange, indeed.

First of all, the action that hangs in your case seems to be "FileCost" - which is a Windows Installer Standard Action.

This action is proprietary to Windows Installer and not something we can control from within Advanced Instaler, so guessing why this happens is quite difficult for me.

Not to mention this "ZwWaitLowEventPair +0x1adda8" from the log file - I have never seen this, ever.

Is there a chance you could share the install package with me via email at support at advancedinstaller dot com so I can run some tests on our ARM laptop? Additionally, a copy of the AIP file and a test-case would really help.

Are you able to reproduce this on multiple machines? Or it happens on your machine only?

I'm asking this because if you can reproduce it on multiple machines, chances are we will be able to reproduce the issue on ours as well, making it easier to investigate and find the culprit.

Best regards,
Catalin

[sasha]

Thanks for the reply, Catalin.

Indeed, this is happening on more than one machine.
And you are absolutely correct that it happens during the 'stock' MSI action. My hope was that you've heard of this before and might know of a solution.

The 'ZwWaitLowEventPair' is not from the log file - it's from a call stack of a busy thread of the msiexec as obtained by the Process Explorer tool while sampled during this condition.

As with the other ARM-related question I posted, I'll try to supply the required bits.

Thanks!

[sasha]

I think I figured the issue out. The root of the problem is that an ‘incorrect’ version of the msiexec.exe was launched. An AMD64 version was launched by our application and that resulted in the hang. With some twiddling I was able to launch an ARM64 version and that worked, just like it would from the command prompt.

Maybe this would be a good tidbit for your FAQ.

Btw, I had to manually remove the aiArm64 launch condition from the .aip file to be able to even run the installer on the ARM64.

Thanks!

[Catalin]

Hello,

Thank you very much for your followup on this and for sharing your solution with us!

As you mentioned, this is indeed FAQ worthy and I will discuss with our technical writing team to add this on our TODO list.

Best regards,
Catalin

[sasha]

Here is some code showing how to launch the correct version. Recall, that our app is x64

// launch via the cmd.exe to ensure the correct architecture is launched. the /machine parameter is available starting with Win11
const cmd = 'cmd.exe /C start /machine arm64 msiexec.exe ' + Command;
ExecuteProcess( cmd, pid ); <--- our wrapper around the CreateProcess API.

[Catalin]

Thank you once again for your followup on this, Alex!

I am sure this will be of help for further users facing a similar scenario.

Best regards,
Catalin