WSL shutdown crashes host PC

[luxzg]

Version

Microsoft Windows [Version 10.0.22621.819]

WSL Version

• WSL 2
• WSL 1

Kernel Version

5.15.68.1-microsoft-standard-WSL2

Distro Version

Ubuntu 22.04

Other Software

systemd
apache2
x11-apps

Repro Steps

It's not exactly reproducible, but I am having this even with pretty clean WSL distro instance.

I have documneted all steps here:
https://github.com/luxzg/WSL2-fixes/blob/master/networkingMode%3Dbridged-ultra-quick.md

I am using the "unsupported" (or hidden) option:
networkingMode=bridged
I use it together with systemd enabled,

If I start the procedure from start I sometimes crash even before installing apache2 and x11-apps, so I don't think it has anything to do with apps installed at later stage of setup, but I'm listing them anyway.

Along the way during setup I have to shutdown WSL using:
wsl.exe --shutdown

So I do exit from WSL session, and then wsl.exe --shutdown but PC crashes.
Sometimes it's blue screen, sometimes it freezes for 5-6 seconds then just reboots, but I always crash PC, then start from the start by unregistering Ubuntu distro.

I've managed to finish the process finally, and it maybe has something to do with me waiting those magical "8-seconds" (more like 10-11 just in case) each time between exit and shutdown. I got to that idea because of the "8 second rule" mentioned in the config docs, even though they relate to different topic.

I am still not 100% sure what causes it. I've been testing WSL for 2 weeks or so, trying stuff, and writing guides in process, and I do remember I had 2 such crashes, but today I've had it 20 times probably, 5-6 times just in last hour. Lost about 1.5 hours of writing in process (I was dumb enough to type directly to GitHub).

I've had it with Ubuntu 20.04 and 22.04.

I'm open to suggestions how to pinpoint what's happening.

Expected Behavior

I run wsl --shutdown and WSL stops, without affecting rest of my PC.

Actual Behavior

Forcefull PC reboot, on 2-3 occasions with short blue screen, usually just reboots.

Diagnostic Logs

No response

[luxzg]

I was feeling extra suicidal, so I decided to crash ASAP...

I only got this far:

wsl.exe --shutdown
wsl.exe --unregister Ubuntu
wsl.exe --install Ubuntu

Entered my username and password 2x

exit
wsl.exe --shutdown

crash

My wslconfig did have bunch of settings inside, but now I know it's not systemd related at least, as I didn't get that far.

Next I tried emptying my .wslconfig then re-adding settings one by one (line by line) with multiple exit/shutdown loops before adding next option, and I've ended up back with whole config as it was, no crash :-/ Will continue trying to reproduce the crash scenario with minimum changes to WSL.

[OneBlue]

Thank you for reporting this @luxzg.

Can you please follow the 10) Reporting a Windows crash (BSOD) section to report this crash ?

[aservedio]

I had a similar issue twice today and yesterday using WSL 1.0.0.0 and first time I was using 0.70.8. Windows 11.

In both cases while issuing wsl --shutdown. No blue screen of death, no special settings. Just like a quick reset as if I had lost power for a second. Not sure if I had my ubuntu 22.04 distro with systemd at true and running when that happend. I'll try paying attention for next time.

[aservedio]

Thank you for reporting this @luxzg.

Can you please follow the 10) Reporting a Windows crash (BSOD) section to report this crash ?

I will do the same. Can we add to that documentation how to undo reg.exe edit after?

[luxzg]

Sorry for delay, I almost gave up thinking that recent updates solved the issue, but I managed today after a bit of stuborn repetitive WSL shutdown/restart looping.

I've sent to instructed inbox, subject "WSL issue 9143 - memory dump - luxzg"

Thing is ... I've noticed that I only got minidumps. Checked System Properties - Startup and Recovery and I have it set with :

• write an event (checked)
• automatically restart (checked)
• write debugging -> small memory dump (256KB)
• %Systemroot%\Minidump

Actual dumps are ~2MB, I had 4 from earlier and this one new.

Do you want me to try and get dumps of other type? If yes, which one?

• Kernel memory dump
• Complete memory dump
• Automatic memory dump
• Active memory dump
  (all 4 have MEMORY.DMP as in instructions, unsure which is most useful for the team)

As aservedio just mentioned, this happened after updates, with WSL 1.0, providing new version info below:

wsl --version
WSL version: 1.0.0.0
Kernel version: 5.15.74.2
WSLg version: 1.0.47
MSRDC version: 1.2.3575
Direct3D version: 1.606.4
DXCore version: 10.0.25131.1002-220531-1700.rs-onecore-base2-hyp
Windows version: 10.0.22621.819

lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:    Ubuntu 22.04.1 LTS
Release:        22.04
Codename:       jammy

4 dumps were with versions as originally reported (111222-....dmp files) last one is with version as reported here now (111722-....dmp)

@aservedio - do you use network bridging maybe, or systemd? You say "no special settings", but just want to confirm. Thanks! Also, check if you have minidumps from those two crashes in C:\Windows\Minidump I'd like to know too.
Because, as you've said, most times I'd just get reboot, black screen, then BIOS. Only few times did I see short second or two blue screen. That would be confirmed by my minidumps, as I only had 4 minidump files out of (without exaggerating) ~20 reboots, well, unless minidumps rotate/delete automatically.

EDIT: And unsure if it helps in any way, but Terminal in which I've been running commands "remembers" this as last command ^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@ I find it interesting, each and every time I get that when I use arrow-up after reboot.

[aservedio]

I took a look into Startup and Recovery settings and I already had the exact same settings @luxzg described above and dump file pointing to %SystemRoot%\Minidump, but no that folder doesn't exist.

I switched it to "Kernel memory dump" and unchecked "Overwrite any existing file". Hopefully I'll get something next time.

My gut feeling from the speed of how it happens, it won't catch anything.

wsl --version output:

WSL version: 1.0.0.0
Kernel version: 5.15.74.2
WSLg version: 1.0.47
MSRDC version: 1.2.3575
Direct3D version: 1.606.4
DXCore version: 10.0.25131.1002-220531-1700.rs-onecore-base2-hyp
Windows version: 10.0.22621.819

Also what I meant by no special settings is that it's all default. I don't know if I am using network bridging to be honest but I know I didn't change any defaults from installation and did not customize the global wslconfig either.

As for systemd yes, I do have one of my WSL distro that has systemd = true in /etc/wsl.conf.

[aservedio]

Well, that didn't take long, and I do have a 2GB MEMORY.DMP file.

My problem now is the instruction method to upload that file as described in 10) Reporting a Windows crash (BSOD) section. This kernel dump is pretty large for an email attachment. None of email services I use today will let me do that. @OneBlue

[aservedio]

Allright I'm able to reproduce my issue consistently. It almost looks like on this Windows 11 PC, if I start 2 WSL distro with systemd enabled, then I can just run wsl --shutdown once or twice and boom, compute restarts with no blue screen. That's on the pc with the wsl --version output above.

For my other PC on Windows 10, I am unable to reproduce this issue using the exact same 2 WSL distros with systemd enabled. And it has this wsl --version output:

WSL version: 1.0.0.0
Kernel version: 5.15.74.2
WSLg version: 1.0.47
MSRDC version: 1.2.3575
Direct3D version: 1.606.4
DXCore version: 10.0.25131.1002-220531-1700.rs-onecore-base2-hyp
Windows version: 10.0.19045.2311

[OneBlue]

Thank you ! We have received the dump and identified the issue.

[luxzg]

Awesome news to wake up to! Then we can skip the 2GB uploads.

Please keep us updated, if it's certain feature like systemd, we can disable it as a workaround maybe. I had few more crashes in the meantime... One with ArchWSL (comes with systemd as default)

[aservedio]

Hello,

Getting back to the initial Windows 11 PC I was able to crash things easily, I am unable to replicate the bug here. It looks fixed from my end!

The only curious thing is I just made sure everything was updated on both windows updates and wsl --update and nothing changed. My current wsl --version output is the same as the initial one I posted above:

WSL version: 1.0.0.0
Kernel version: 5.15.74.2
WSLg version: 1.0.47
MSRDC version: 1.2.3575
Direct3D version: 1.606.4
DXCore version: 10.0.25131.1002-220531-1700.rs-onecore-base2-hyp
Windows version: 10.0.22621.819

[luxzg]

I could say the same, but I have to say I've actually "eased up" a little on shutdowns, and I'm rather cautious and wait a little for distro to exit itself. I'm in no mood of causing any real damage to my only working PC at this moment :) Anyway, I haven't had BSOD or forced reset since November 18th. But like I've said, I've tried to be gentle as well. I did run same procedure on ArchWSL, Debian, and today on kali-linux, trying to confirm my tutorials cover distros people ask me about. I hope BSOD is done, but I'll keep being careful until I read about it in release notes.

[aservedio]

Bummer, I was able to re-create the same crash I initially had. I did not intend to test that this time.

Next time I need to wsl --shutdown, I'll make sure I'm ready to crash 😥

[luxzg]

@aservedio I got the info it should be officially patched in 2 days.

[luxzg]

2022-12 Cumulative Update for Windows 11 (KB5021255) reportedly includes patch for this issue.

[obriat]

What about Windows 10 ? Which update fix this problem ?

[obriat]

I confirme that after enabling systemd, my Windows 10 crashes a lot: BSOD or sudden reboot, but mostly during sleep mode. I switch back to systemd off and no more problems.

[luxzg]

@obriat did you patch W10 with latest Windows Updates? I don't know if patch was released for W10, but it was shipped in regular Windows Update for W11.

[rs38]

same here, I can provide crash dump etc. if it helps?!
(Win11 latest 22H2, bust just before KB5025305)

[rs38]

still the same here...really no progress on that?
(Win11 latest 22H2)

really wonder why msrdc.exe is mentioned (wasn't rdp*ing at all)

  Kernel Generated Triage Dump

BUGCHECK_CODE:  18

BUGCHECK_P1: 0

BUGCHECK_P2: ffff8e050be26da0

BUGCHECK_P3: 2

BUGCHECK_P4: fffffffffffffffe

BLACKBOXBSD: 1 (!blackboxbsd)


BLACKBOXNTFS: 1 (!blackboxntfs)


BLACKBOXPNP: 1 (!blackboxpnp)


BLACKBOXWINLOGON: 1

CUSTOMER_CRASH_COUNT:  1

PROCESS_NAME:  msrdc.exe

STACK_TEXT:  
fffff08f`f4494288 fffff807`3a2bed13     : 00000000`00000018 00000000`00000000 ffff8e05`0be26da0 00000000`00000002 : nt!KeBugCheckEx
fffff08f`f4494290 fffff807`3a5cb564     : 00000000`00000001 00000000`00000001 00000000`00000ea4 ffffcf0d`7736b3c0 : nt!ObfDereferenceObjectWithTag+0x1aa513
fffff08f`f44942d0 fffff807`3a5c9cb9     : 00000183`a3d0cf80 00000000`00000001 00000000`00000ea4 00000000`00000db4 : nt!ObpCloseHandle+0x2a4
fffff08f`f44943f0 fffff807`3a2274e5     : ffff8e05`12aaa080 00000060`613ff200 00000183`a52abd01 00000000`00000000 : nt!NtClose+0x39
fffff08f`f4494420 00007ffc`1238f5d4     : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KiSystemServiceCopyEnd+0x25
00000060`613ff508 00000000`00000000     : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : 0x00007ffc`1238f5d4


SYMBOL_NAME:  nt!ObfDereferenceObjectWithTag+1aa513

MODULE_NAME: nt

IMAGE_NAME:  ntkrnlmp.exe

IMAGE_VERSION:  10.0.22621.2428

STACK_COMMAND:  .cxr; .ecxr ; kb

BUCKET_ID_FUNC_OFFSET:  1aa513

FAILURE_BUCKET_ID:  0x18_CORRUPT_REF_COUNT_nt!ObfDereferenceObjectWithTag

OSPLATFORM_TYPE:  x64

OSNAME:  Windows 10

FAILURE_ID_HASH:  {fa6b3516-71cb-1e92-b987-b8bebd3458ac}

Followup:     MachineOwner
---------

[OneBlue]

This issue has been fixed in Windows and the fix is part of kb 5021255

[rs38]

@OneBlue are you kidding me?!
I provide current evidence of an up2date 2023 Win11 and you say it's fixed?!
No it's not fixed

[OneBlue]

@OneBlue are you kidding me?! I provide current evidence of an up2date 2023 Win11 and you say it's fixed?! No it's not fixed

You're most likely hitting something different. Please follow these instructions to share a kernel dump with us.