search

The-Virtual-Desktop-Team / Virtual-Desktop-Optimization-Tool

The script and configuration files in this repository provide an easy method to customize and apply performance related settings to virtual desktop environments.
675 stars 168 forks source link

Explorer.exe crash and taskbar is transparent #207

Open okinobk opened 3 months ago

okinobk commented 3 months ago

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"

1000 0 2 100 0 0x8000000000000000 60070 Application **** explorer.exe 10.0.22621.3527 00c8ba7a Windows.UI.FileExplorer.dll 10.0.22621.3527 b4356edb c0000005 0000000000016f59 0xa3ec 0x1daaaa0e6a4260d C:\WINDOWS\explorer.exe C:\WINDOWS\system32\Windows.UI.FileExplorer.dll 2ef62886-ecf8-4192-8244-b816bfea420b

`

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 commented 3 months ago

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 commented 3 months ago

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

okinobk commented 3 months ago

@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 commented 3 months ago

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 commented 3 months ago

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 commented 3 months ago

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.