0

I'm installing a WiX standard bootstrapper to install several packages in a Chain. The bootstrapper shows up in the list of installed Apps & Features. I can use the entry to uninstall our software on most systems, but on others, nothing visibly happens after confirming that I want to allow modifications to the system.

When comparing to another PC (both Win 10, different editions) where the uninstall process starts properly, I find that the command lines of the launched process install.exe differ, see this Process Explorer screenshot for the functioning case and this screenshow of the disfunctional case. The latter case shows no installer window, and install.exe doesn't load a few DLLs it otherwise would, such as CoreMessaging.dll, CoreUIComponents.dll, explorerframe.dll, etc.

So for some reason, the executable is copied from its location in the package cache to the Windows temp folder. If I open the command shell and navigate to the temp location, I can launch install.exe /uninstall just fine.

Why does the system copy the installer to the temp folder? How can I debug this - I cannot find anything in the system event log, and the bootstrapper log ends after a few lines, when the log file location has been reported.

Thank you very much for your help!

Regards, Holger

Edit 1:

Given that the execution from either the package cache of from the Windows temp folder is irrelevant for this issue, I have attached a debugger, using the debugging symbols of burn. In the problematic case, the main thread is stuck in UiCreateMessageWindow in the line 63:

// Wait for either the thread to be initialized or the window to exit / fail prematurely.
::WaitForMultipleObjects(countof(rgWaitHandles), rgWaitHandles, FALSE, INFINITE);

Edit 2:

This is the call stack of the thread that the WaitForMultipleObjects call waits for:

ntdll.dll!_NtAlpcSendWaitReceivePort@32()   Unknown
rpcrt4.dll!LRPC_BASE_CCALL::SendReceive()   Unknown
rpcrt4.dll!NdrClientCall2() Unknown
rpcrt4.dll!_NdrClientCall4()    Unknown
combase.dll!CRpcResolver::ServerRegisterOXID(const tagOXID_INFO & oxidInfo, unsigned __int64 * poxid, unsigned long * pcOidsToAllocate, unsigned __int64 * arNewOidList) Line 1109  C++
combase.dll!OXIDEntry::RegisterOXIDAndOIDs(unsigned long * pcOids, unsigned __int64 * pOids) Line 1598  C++
combase.dll!OXIDEntry::AllocOIDs(unsigned long * pcOidsAlloc, unsigned __int64 * pOidsAlloc, unsigned long cOidsReturn, unsigned __int64 * pOidsReturn) Line 1639   C++
combase.dll!CComApartment::CallTheResolver() Line 862   C++
combase.dll!CComApartment::InitRemoting() Line 1141 C++
combase.dll!InitChannelIfNecessary() Line 1492  C++
combase.dll!CGIPTable::RegisterInterfaceInGlobalHlp(IUnknown * pUnk, const _GUID & riid, unsigned long mshlflags, unsigned long * pdwCookie) Line 798   C++
combase.dll!CGIPTable::RegisterInterfaceInGlobal(IUnknown * pUnk, const _GUID & riid, unsigned long * pdwCookie) Line 759   C++
propsys.dll!CApartmentLocalObject::_RegisterInterfaceInGIT()    Unknown
propsys.dll!CApartmentLocalObject::_SetApartmentObject(struct IUnknown *)   Unknown
propsys.dll!CApartmentLocalObject::SetApartmentObject(struct IUnknown *)    Unknown
propsys.dll!PSCoerceToCanonicalValue()  Unknown
windows.storage.dll!AssocCoerceKinds()  Unknown
windows.storage.dll!_AssocGetKindsForExtension@12() Unknown
windows.storage.dll!CFileAssocList::InitializeWithExtension(unsigned short const *) Unknown
windows.storage.dll!AssocCreateListForFile()    Unknown
windows.storage.dll!AssocCreateForFile()    Unknown
windows.storage.dll!CFileSysItemString::_EnsureAssocArray() Unknown
windows.storage.dll!CFSFolder::_GetNormalDisplayName()  Unknown
windows.storage.dll!CFSFolder::GetDisplayNameOf()   Unknown
shell32.dll!_DisplayNameOfW@20()    Unknown
shell32.dll!_GetFileInfoSections()  Unknown
shell32.dll!SHGetFileInfoW()    Unknown
shell32.dll!_SHGetFileInfoWStub@20()    Unknown
comdlg32.dll!_GetFileTitleX@12()    Unknown
comdlg32.dll!_GetFileTitleW@12()    Unknown
tiptsf.dll!CImmersiveFocusTracker::_IsWinJSApp(void)    Unknown
tiptsf.dll!CImmersiveFocusTracker::CImmersiveFocusTracker(void) Unknown
tiptsf.dll!`dynamic initializer for 'CImmersiveFocusTracker::s_theTracker''()   Unknown
msvcrt.dll!__initterm() Unknown
tiptsf.dll!__CRT_INIT@12()  Unknown
tiptsf.dll!__DllMainCRTStartup()    Unknown
ntdll.dll!_LdrxCallInitRoutine@16() Unknown
ntdll.dll!LdrpCallInitRoutine() Unknown
ntdll.dll!LdrpInitializeNode()  Unknown
ntdll.dll!LdrpInitializeGraphRecurse()  Unknown
ntdll.dll!LdrpPrepareModuleForExecution()   Unknown
ntdll.dll!LdrpLoadDllInternal() Unknown
ntdll.dll!LdrpLoadDll() Unknown
ntdll.dll!LdrLoadDll()  Unknown
KernelBase.dll!LoadLibraryExW() Unknown
user32.dll!__ClientLoadLibrary()    Unknown
ntdll.dll!_KiUserCallbackDispatcher@12()    Unknown
user32.dll!CreateWindowInternal()   Unknown
user32.dll!_CreateWindowExW@48()    Unknown
install.exe!ThreadProc(void * pvContext) Line 138   C++
kernel32.dll!@BaseThreadInitThunk@12()  Unknown
ntdll.dll!__RtlUserThreadStart()    Unknown
ntdll.dll!__RtlUserThreadStart@8()  Unknown
drhose
  • 1
  • 2
  • Looks like a bug - maybe look at the old [5724](https://github.com/wixtoolset/issues/issues/5724) fix [for latest official release](https://github.com/wixtoolset/wix3/releases/tag/wix3111rtm). [Throwing in a link to similar issue](https://stackoverflow.com/questions/55404271/wix-v3-setup-project-unable-to-uninstall-via-apps-features) - not quite the same. – Stein Åsmul Sep 21 '19 at 02:27
  • On the PC where it's not working, have they [redirected the package cache](https://devblogs.microsoft.com/setup/redirect-the-package-cache-using-registry-based-policy/)? – Sean Hall Sep 21 '19 at 21:42
  • Thanks for your replies! The non-working PC actually was a few Windows updates behind. Upon applying them, there's no longer a difference in the command lines (both starting directly from the package cache), but the behavior is unchanged - except that it **once** started as intended from Apps & Features. I wasn't able to reproduce this wanted behavior, though. The package cache isn't redirected. – drhose Sep 23 '19 at 09:01
  • I've added **Edit 1** to add my findings from debugging. Hopefully, this helps clarifying the issue. – drhose Sep 23 '19 at 12:25
  • It's probably AV interference. If you wanted to debug further, you would have to see why the thread never signaled the event (the thread started on line 59, which should signal it on line 142). When replying to comments, you should @ the person so they get notified. – Sean Hall Sep 23 '19 at 22:30
  • Thanks, @SeanHall - also for the advice on notifying! The thread process whose signal the WaitForMultipleObjects call awaits calls ::CreateWindowExW in ThreadProc. A call to LoadLibraryExW, which uses combase.dll and rpcrt4.dll, doesn't return. – drhose Sep 24 '19 at 07:30
  • I've added the call stack of the blocking thread in **Edit 2**, @SeanHall. Does the problem loading tiptsf.dll support your hypothesis of AV interference? – drhose Sep 25 '19 at 10:11

0 Answers0