Explorer.exe crash and taskbar is transparent

[okinobk]

Hello,
I'm sorry if I raised the ticket here and VDOT is not responsible for the issue at all. It's my last try, because it's happening only in servers where VDOT was applied.

After some Windows 11 Enterprise multisession updates in Azure (as session host for AVD) problems appears with explorer.exe and taskbar. The taskbar is transparent and not responding and explorer.exe is crashing with error:
Log Name: Application Source: Application Error Date: 5/20/2024 12:33:26 PM Event ID: 1000 Task Category: Application Crashing Events Level: Error Keywords: User: ****\test.user Computer: **** Description: Faulting application name: explorer.exe, version: 10.0.22621.3527, time stamp: 0x00c8ba7a Faulting module name: Windows.UI.FileExplorer.dll, version: 10.0.22621.3527, time stamp: 0xb4356edb Exception code: 0xc0000005 Fault offset: 0x0000000000016f59 Faulting process id: 0x0xA3EC Faulting application start time: 0x0x1DAAAA0E6A4260D Faulting application path: C:\WINDOWS\explorer.exe Faulting module path: C:\WINDOWS\system32\Windows.UI.FileExplorer.dll Report Id: 2ef62886-ecf8-4192-8244-b816bfea420b Faulting package full name: Faulting package-relative application ID: Event Xml: <Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event" <System> <Provider Name="Application Error" Guid="{a0e9b465-b939-57d7-b27d-95d8e925ff57}" /> <EventID>1000</EventID> <Version>0</Version> <Level>2</Level> <Task>100</Task> <Opcode>0</Opcode> <Keywords>0x8000000000000000</Keywords> <TimeCreated SystemTime="2024-05-20T10:33:26.4790728Z" /> <EventRecordID>60070</EventRecordID> <Correlation /> <Execution ProcessID="16956" ThreadID="18704" /> <Channel>Application</Channel> <Computer>****</Computer> <Security UserID="****" /> </System> <EventData> <Data Name="AppName">explorer.exe</Data> <Data Name="AppVersion">10.0.22621.3527</Data> <Data Name="AppTimeStamp">00c8ba7a</Data> <Data Name="ModuleName">Windows.UI.FileExplorer.dll</Data> <Data Name="ModuleVersion">10.0.22621.3527</Data> <Data Name="ModuleTimeStamp">b4356edb</Data> <Data Name="ExceptionCode">c0000005</Data> <Data Name="FaultingOffset">0000000000016f59</Data> <Data Name="ProcessId">0xa3ec</Data> <Data Name="ProcessCreationTime">0x1daaaa0e6a4260d</Data> <Data Name="AppPath">C:\WINDOWS\explorer.exe</Data> <Data Name="ModulePath">C:\WINDOWS\system32\Windows.UI.FileExplorer.dll</Data> <Data Name="IntegratorReportId">2ef62886-ecf8-4192-8244-b816bfea420b</Data> <Data Name="PackageFullName"> </Data> <Data Name="PackageRelativeAppId"> </Data> </EventData> </Event>

The issue impacts every user except built-in (local) administrator and domain administrator. These users had profile created before VDOT was applied to VM. Same issue in 2 VMs, both with VDOT applied, after Windows updates and restart.

I found KB5035853 mentioned many times connected to taskbar transparency problem. Also, almost everyone has problem connected to other opensource project https://github.com/valinet/ExplorerPatcher.
In this project I discovered release which should consists the fix: https://github.com/valinet/ExplorerPatcher/releases/tag/22621.3296.64.1_9e9c016
In the some commits is mentioned: "Fixed a bug where SCOOBE would repeatedly crash Explorer when Language Switcher is set to anything other than Windows 11"

I don't use ExplorerPatcher, but I use VDOT. So my implication is telling me that problem can be based on VDOT also.

I found same changes in SCOOBE by VDOT, in registry "ScoobeSystemSettingEnabled". I tried to change it (probably back to default value) to "1" and relogin test user, but without any success.

Is it possible that VDOT causes this issue?

Thank you in advance for any help.

[okinobk]

I tested the situation with other Windows 11 and I can confirm that issue is because of VDOT. Same server type, with same updates, without VDOT applied is without any issue.

[tmmuessig]

@okinobk - Can you share what your configuration files look like or list any changes you've made to them for your environment?

[okinobk]

@tmmuessig I used default configuration files, except AppxPackages.json. All config files attached here:
configs.zip

I executed:
.\Windows_VDOT.ps1 -Optimizations All -AcceptEULA -Verbose

[sp1nkick]

I think we are running into this issue as well. Let me know if I can help. I'm going to recreate the server w/o VDOT and see if it goes away as a first test.

[robsmi-msfte]

Hello @okinobk,

After the crash happened, there should have been a Windows Error Report created, perhaps one per crash. Those reports are saved in this folder, by default:

%ProgramData%\Microsoft\Windows\WER\ReportArchive

If you could get one or two of the largest files in those folders (memory dump files), that are for Explorer.exe crash reports. Those might be .mdmp or .hdmp.

DO NOT attach those to this thread or try to e-mail. Those could contain PII. Instead, find a secure sharing method, maybe OneDrive. Put those in there, create a time-limited share, send us the link. I will take a look and see if I can figure out what's going on. Or if you have some other equivalent file sharing method, use that.

I did look at the configuration files you sent, and I don't see anything unusual with those. They all look very standard to me.

Thanks,

Robert M. Smith

[robsmi-msfte]

BTW, SCOOBE is "Second Chance Out of the Box Experience". It invokes a wizard that I have seen sometimes after a cumulative update or for sure for a milestone update that is something like "Let's finish setting up your device"
The setting in VDOT suppresses SCOOBE because if those settings are already set by policy, especially in the enterprise, there is no need to invoke that again.

[oliverkrage93]

Is this resolved?

[okinobk]

@oliverkrage93 The issue was resolved and it turned out that VDOT was not involved after all.

The issue was due to disabled Windows Store services. We resolved it by:

• Reactivate Windows Services AppXSvc a Clipsvc:
  HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\AppXSvc\Start set value to 3 (Manual (Trigger Start))
  HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\Clipsvc\Start set value to 3 (Manual (Trigger Start))
• Deactivate GPO "Disable-WindowsStore" or set local computer policy by "gedit.msc -> Local Computer Policy -> Computer Configuration -> Administrative Templates -> Windows Components -> Store -> Turn off the Store application - Not Configured"
• Check/set registry:
  Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\WindowsStore set value to 0