From Newsgroup: alt.comp.os.windows-11

The basic symptom is:
Running system gives "black screen"
HID devices are disabled. Plugging in a new HID device, it is ignored on purpose.
With no keyboard, you cannot ctrl-alt-delete or any other input value.
NIC is disabled, LEDs go off on it.
USB ports *do* have power, but some detection constraint prevents usage.
In the past, no EventVwr.msc log entry, was available. But some
things can be logged, like Watchdogs can be logged.

At one point, while working on it, it became SO BAD, I couldn't even type in the PIN before the computer black screened. It was not inclined in that case, to wait 60 seconds before dropping. Previously it would only do these about once a week. There could be periods where it stopped happening entirely,
but it's been a dumpster fire recently. If I log in with my second profile,
it is all "sweetness and light" and the frequency of the event and the predictability are a lot lower.

Memtest passes. I ran it earlier today. Linux operates on this computer, without a problem. Hmmm.

*******

That's not the same as this. The video card has a watchdog, and the video card driver is supposed to have a recovery procedure. It takes a second or so
for a card to recover, normally. Microsoft has improved the behavior on some
of these, such that you can only see them happening via using the Reliability Monitor.
The suspicion is, these are not necessarily turning off the monitor.

C:\ProgramData\NVIDIA\NVDisplayContainerWatchdog.log

#0(I)[2026-10-19 03:15:47,473]{00000FC8}<NvpChildProcess> Container 00000000000009BC for C:\WINDOWS\System32\DriverStore\FileRepository\nv_dispig.inf_amd64_f4c7a2fd13e0f763\Display.NvContainer\plugins\Session exited with C0000005
#1(D)[2026-10-19 03:15:47,473]{00000FC8}<DirectoryEnumera> Process file C:\WINDOWS\System32\DriverStore\FileRepository\nv_dispig.inf_amd64_f4c7a2fd13e0f763\Display.NvContainer\plugins\Session/nvprofileupdaterplugin.dll
#2(D)[2026-10-19 03:15:47,473]{00000FC8}<DirectoryEnumera> OnItem returned FALSE for file C:\WINDOWS\System32\DriverStore\FileRepository\nv_dispig.inf_amd64_f4c7a2fd13e0f763\Display.NvContainer\plugins\Session/nvprofileupdaterplugin.dll
#3(I)[2026-10-19 03:15:47,473]{00000FC8}<NvpChildProcess> Container in session 2 new crash count 5
#4(E)[2026-10-19 03:15:47,473]{00000FC8}<NvpChildProcess> Container in session 2 crash rate 0.000479 exceeded maximum 0.000033. Count 5. Disable it
#5(E)[2026-10-19 03:15:47,473]{00000FC8}<NvpChildProcess> Container for C:\WINDOWS\System32\DriverStore\FileRepository\nv_dispig.inf_amd64_f4c7a2fd13e0f763\Display.NvContainer\plugins\Session will not be restarted due to policy 10/300
#6(D)[2026-10-19 03:15:47,473]{00000FC8}<DirectoryEnumera> Process file C:\WINDOWS\System32\DriverStore\FileRepository\nv_dispig.inf_amd64_f4c7a2fd13e0f763\Display.NvContainer\plugins\Session/nvprofileupdaterplugin.dll
#7(D)[2026-10-19 03:15:47,473]{00000FC8}<DirectoryEnumera> OnItem returned FALSE for file C:\WINDOWS\System32\DriverStore\FileRepository\nv_dispig.inf_amd64_f4c7a2fd13e0f763\Display.NvContainer\plugins\Session/nvprofileupdaterplugin.dll
#8(D)[2026-10-19 03:15:47,473]{00000FC8}<NvpChildGroup> Group => #9(D)[2026-10-19 03:15:47,473]{00000FC8}<NvpChildGroup> Folder: C:\WINDOWS\System32\DriverStore\FileRepository\nv_dispig.inf_amd64_f4c7a2fd13e0f763\Display.NvContainer\plugins\Session
#0(D)[2026-10-19 03:15:47,473]{00000FC8}<NvpChildGroup> Container: elevated - C:\WINDOWS\System32\DriverStore\FileRepository\nv_dispig.inf_amd64_f4c7a2fd13e0f763\Display.NvContainer\NVDisplay.Container.exe
#1(D)[2026-10-19 03:15:47,473]{00000FC8}<NvpChildGroup> Parameters: -f %ProgramData%\NVIDIA\DisplaySessionContainer%d.log -d C:\WINDOWS\System32\DriverStore\FileRepository\nv_dispig.inf_amd64_f4c7a2fd13e0f763\Display.NvContainer\plugins\Session -r -l 3 -p 30000 -cfg NVDisplay.ContainerLocalSystem\Session /ert
#2(D)[2026-10-19 03:15:47,473]{00000FC8}<NvpChildGroup> Processes => #3(D)[2026-10-19 03:15:47,473]{00000FC8}<NvpChildProcess> Session 1, process 0000000000000000
#4(D)[2026-10-19 03:15:47,473]{00000FC8}<NvpChildProcess> Session 2, process 0000000000000000
#5(D)[2026-10-19 03:15:47,473]{00000FC8}<NvpWatchdog> Wait for 3 handles. Timeout = 4294967295

Apparently, the kernel also has some detections. This might not be
making the screen go black, as this iGPU is not driving the screen,
and I only turned it on to "fuzz the problem" and try to make it
so the stupid PC would continue to run.

Problem

Hardware error

Description
A problem with your hardware caused Windows to stop working correctly.

Problem signature
Problem Event Name: LiveKernelEvent
Code: 1b0
Parameter 1: aaaaaaaaaaaaaaaa
Parameter 2: aaaaaaaaaaaaaaaa
Parameter 3: aaaaaaaaaaaaaaaa
Parameter 4: aaaaaaaaaaaaaaaa
OS version: 10_0_26200
Service Pack: 0_0
Product: 768_1
OS Version: 10.0.26200.2.0.0.768.101
Locale ID: 1033

Extra information about the problem
Bucket ID: LKD_0x1B0_DxgkrlLiveDump:804_Status_0xC0000001_Driver_amdkmdag_failed_DdiStartDevice_dxgkrnl!DxgCreateLiveDumpWithDriverBlob

Date Sun, 10/18/2026 2:16 PM

*******

One of the problems with Windows 11, is not all the "installed software"
has convenient entries related to "uninstall". There is NVidia software
on the machine, there is NVidia telemetry (telemetry is an OPTIONAL behavior, and is not essential to the driver staying upright). The telemetry module
seems to be implicated. NVDisplayContainer seems to be part of that
telemetry thing. There were also four entries in Task Schedule, which
cause the NVidia "package" to go after telemetry. Those were discovered
years ago in Scheduled Tasks. They are unlikely to be disabled on this machine, but I disabled them one time on Win10 or so.

If I wanted to remove the Telemetry package NVDisplayContainer. that's
going to be a challenge (Revo Uninstaller?). The actual driver is a hard-working Ring0 kind of thing. The NVDisplayContainer and its "nvcpl.dll" seem separate from it. Because it's generating a logfile, it could be in Ring3,
or if virtualized, maybe in Ring2.

*******

I turned on the iGPU originally, just to see if it alone would work.
It appears the NVDisplay.Container.exe might still be running.
I put the GTX 1650 back in, and the box is now staying up while my
regular account (MSA) is the one being used. This should return me
to the "random" rate of droppage, rather than dying in 60 seconds or less.

A tool like DDU ("Driver Cleaner") might not be enough for this, as NVDisplay.Container is a separate item. People claim to have run it,
without symptoms improvement, suggesting it is not a "general system carwash". That's one reason I haven't used it, so far. No modern claims of it
performing a miracle. That program may have been referred to as
"Detonator Destroyer" in an earlier time (I had used it and it worked then).

If the NVDisplay.Container does not have an App entry, nor a Programs and Features
entry, then maybe it will have to be located via the .msi cache. Maybe I
need to get Revo Uninstaller involved ??? Of course, the next time the oh-so-fine Windows Update gets in there, it's going to put that garbage
right back there.

[Picture] Black-screen-breadcrumbs.png

https://imgur.com/a/ooJPBtt

https://postimg.cc/21zz64P9
https://i.postimg.cc/W1Zt58SV/Black-screen-breadcrumbs.png

Paul



--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: alt.comp.os.windows-11

On Mon, 10/19/2026 3:17 AM, Paul wrote:

The basic symptom is:
Running system gives "black screen"
HID devices are disabled. Plugging in a new HID device, it is ignored on purpose.
NIC is disabled, LEDs go off on it.

The really interesting part, was when the machine dropped dead while in the middle of the PIN prompt, the machine carried out a diagnose+repair
sequence and it may have changed something. But because it doesn't
tell you what it did, I have no way of knowing why the machine
is staying up today. Was it something I did (such as turning the iGPU
back on, which at first had not helped), or was it something
during the diagnose+repair ?

C:\Windows\System32\LogFiles\Srt\SrtTrail.txt

Test Performed:
---------------------------
Name: Detect remediation via cloud plugins
Result: Completed successfully. Error code = 0x0 <=== all of the tests, did this...
Time taken = 7235 ms

Paul
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: alt.comp.os.windows-11

On 10/19/2026 3:17 AM, Paul wrote:

The basic symptom is:
Running system gives "black screen"
HID devices are disabled. Plugging in a new HID device, it is ignored on purpose.
With no keyboard, you cannot ctrl-alt-delete or any other input value.
NIC is disabled, LEDs go off on it.
USB ports *do* have power, but some detection constraint prevents usage.
In the past, no EventVwr.msc log entry, was available. But some
things can be logged, like Watchdogs can be logged.

At one point, while working on it, it became SO BAD, I couldn't even type in the PIN before the computer black screened. It was not inclined in that case, to wait 60 seconds before dropping. Previously it would only do these about once a week. There could be periods where it stopped happening entirely,
but it's been a dumpster fire recently. If I log in with my second profile, it is all "sweetness and light" and the frequency of the event and the predictability are a lot lower.

Are you indicating that the exact same issue occurs in the second
profile but after the ability to logon(enter pin, access desktop and
account settings, etc.) before locking up.

If so, please define what you meant by frequency(minutes, hours)?
--
...w¡ñ§±¤ñ
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: alt.comp.os.windows-11

On Mon, 10/19/2026 2:57 PM, ....winston wrote:

On 10/19/2026 3:17 AM, Paul wrote:

The basic symptom is:
Running system gives "black screen"
HID devices are disabled. Plugging in a new HID device, it is ignored on purpose.
With no keyboard, you cannot ctrl-alt-delete or any other input value.
NIC is disabled, LEDs go off on it.
USB ports *do* have power, but some detection constraint prevents usage.
In the past, no EventVwr.msc log entry, was available. But some
things can be logged, like Watchdogs can be logged.

At one point, while working on it, it became SO BAD, I couldn't even type in >> the PIN before the computer black screened. It was not inclined in that case,
to wait 60 seconds before dropping. Previously it would only do these about >> once a week. There could be periods where it stopped happening entirely,
but it's been a dumpster fire recently. If I log in with my second profile, >> it is all "sweetness and light" and the frequency of the event and the
predictability are a lot lower.

Are you indicating that the exact same issue occurs in the second profile but after the ability to logon(enter pin, access desktop and account settings, etc.) before locking up.

If so, please define what you meant by frequency(minutes, hours)?

It used to happen once a week, at random.

Recently, it changed to being quite reproducible.
Boot the computer, use my Daily Driver profile, login,
after around 60 second, screen would go black, all HID disabled,
USB ports *do* have power, but device LED only "blinks" as
the OS perhaps reads the config space.

If I log in with a second profile ("Bullwinkle"), it would
stay up for longer.

Figuring this was the containerized Nvidia driver doing this,
I turned on the iGPU as well as leaving the NVidia card installed.
Now, on the Daily Driver profile, I couldn't even type in the PIN,
it dropped so fast. I would not have been able to select "Bullwinkle"
profile either.

It was during this super-fast in-the-middle-of-login failure,
the computer started doing a "diagnose" with the spinning icon,
and it must have changed something. Looking in the SRT trail folder,
there is lots of activity, but nothing that points to a specific cure.
I do not believe, for example, that any sort of DISM command can
finish in seven seconds. Maybe if a health issue was logged previously,
it could harvest that.

*******

When the machine was assembled by me originally, it was flawless.
I ran using just the iGPU for several months. Then, one day, it started...

The RealTek NIC would drop out, around 30 seconds after the desktop appeared. This was reproducible, each time, the same time constant. Changing driver
did not help. (Today, the RealTek NIC is containerized as I understand it.)

I replaced the RealTek NIC with an Intel NIC card. Good so far.

Then, later, the iGPU started doing the black screen thing (Vega 8
on the Zen3 5700G 8 core). I installed a $200 video card from the
computer store, a GTX1650. I turned off the iGPU. Things were fine for
a while. Some months, I could go the whole month, without an event.
Other times, it would be about once a week.

Just recently, the condition became "no longer random". taskschd.msc
no longer has any NVidia tasks (there used to be four of them
related to NVidia telemetry). Can't blame it on that then. Something
else is triggering the NVidia behavior (I think something is attempting
to contact the driver and is not succeeding). I changed driver back
to an older one, didn't help. It's hard to tell what Nvidia software
is installed, as there is nothing in Apps, nothing in Programs and Features. And there is no C:\NVidia folder, where sometimes installers unpack themselves. The C:\AMD folder still exists for the AMD video driver of the iGPU (Vega8).

By "no longer random", with just the GTX1650, the screen would go black
about 60 seconds after entering the PIN. That's the GTX1650, with the
iGPU switched off. Then, after trying a few more things, I couldn't
even change the PIN (or select "Bullwinkle" secondary profile). But
when that happened, finally windows used the "Diagnose" spinner. And
somehow, I'm running and the Reliability Monitor is not showing any
"NVidia Container" entries for today so far. The 4K monitor is being
driven by the GTX1650 HDMI out.

If I do memtest, it passes.

If I run Linux, it's fine. I've never seen a "similar symptom" while testing Linux on this machine. I could "make a kernel panic" in the past,
via overclocking one of my older single-core machines :-) You can still have boot failures on poorly prepared distros. The worst distros are a sight
to behold (desktop won't start, mouse stops working). But a Ubuntu
or a Linux Mint, is generally well prepared and works fine. And no
symptoms that "smell of hardware level trouble".

I have debugged other problems, via comparison analysis. Run Windows,
get a crash in 20 seconds. Run Linux, get a crash in 20 seconds
(Linux twitching before it dies). This is part of a hardware issue
with the 440BX chipset on Intel. Originally I was blaming Windows,
but when I got the Linux result, then I knew it was hardware and
the address map for memory was somehow not right. Installing 768MB
of memory on 440BX, spells instant trouble (256MB+256MB+256MB).
Slightly less than 768MB, you could run Prime95 for 16 hours with no problem
at all (256MB+256MB+128MB+64MB). Very stable, and using
four sticks of RAM too on a single channel bus.

Summary: While I'm running on my Daily Driver profile right now,
I really don't know what will happen next. And with no evidence
of what has changed to stop it, I won't know what to do or where
to go the next time. You'll notice I'm not volunteering to do
a Clean Install (yet).

Paul
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: alt.comp.os.windows-11

On 10/20/2026 12:00 AM, Paul wrote:

On Mon, 10/19/2026 2:57 PM, ....winston wrote:

On 10/19/2026 3:17 AM, Paul wrote:

The basic symptom is:
Running system gives "black screen"
HID devices are disabled. Plugging in a new HID device, it is ignored on purpose.
With no keyboard, you cannot ctrl-alt-delete or any other input value.
NIC is disabled, LEDs go off on it.
USB ports *do* have power, but some detection constraint prevents usage. >>> In the past, no EventVwr.msc log entry, was available. But some
things can be logged, like Watchdogs can be logged.

At one point, while working on it, it became SO BAD, I couldn't even type in
the PIN before the computer black screened. It was not inclined in that case,
to wait 60 seconds before dropping. Previously it would only do these about >>> once a week. There could be periods where it stopped happening entirely, >>> but it's been a dumpster fire recently. If I log in with my second profile, >>> it is all "sweetness and light" and the frequency of the event and the
predictability are a lot lower.

Are you indicating that the exact same issue occurs in the second profile but after the ability to logon(enter pin, access desktop and account settings, etc.) before locking up.

If so, please define what you meant by frequency(minutes, hours)?

It used to happen once a week, at random.

Recently, it changed to being quite reproducible.
Boot the computer, use my Daily Driver profile, login,
after around 60 second, screen would go black, all HID disabled,
USB ports *do* have power, but device LED only "blinks" as
the OS perhaps reads the config space.

If I log in with a second profile ("Bullwinkle"), it would
stay up for longer.

Figuring this was the containerized Nvidia driver doing this,
I turned on the iGPU as well as leaving the NVidia card installed.
Now, on the Daily Driver profile, I couldn't even type in the PIN,
it dropped so fast. I would not have been able to select "Bullwinkle"
profile either.

It was during this super-fast in-the-middle-of-login failure,
the computer started doing a "diagnose" with the spinning icon,
and it must have changed something. Looking in the SRT trail folder,
there is lots of activity, but nothing that points to a specific cure.
I do not believe, for example, that any sort of DISM command can
finish in seven seconds. Maybe if a health issue was logged previously,
it could harvest that.

*******

When the machine was assembled by me originally, it was flawless.
I ran using just the iGPU for several months. Then, one day, it started...

The RealTek NIC would drop out, around 30 seconds after the desktop appeared. This was reproducible, each time, the same time constant. Changing driver
did not help. (Today, the RealTek NIC is containerized as I understand it.)

I replaced the RealTek NIC with an Intel NIC card. Good so far.

Then, later, the iGPU started doing the black screen thing (Vega 8
on the Zen3 5700G 8 core). I installed a $200 video card from the
computer store, a GTX1650. I turned off the iGPU. Things were fine for
a while. Some months, I could go the whole month, without an event.
Other times, it would be about once a week.

Just recently, the condition became "no longer random". taskschd.msc
no longer has any NVidia tasks (there used to be four of them
related to NVidia telemetry). Can't blame it on that then. Something
else is triggering the NVidia behavior (I think something is attempting
to contact the driver and is not succeeding). I changed driver back
to an older one, didn't help. It's hard to tell what Nvidia software
is installed, as there is nothing in Apps, nothing in Programs and Features. And there is no C:\NVidia folder, where sometimes installers unpack themselves.
The C:\AMD folder still exists for the AMD video driver of the iGPU (Vega8).

By "no longer random", with just the GTX1650, the screen would go black
about 60 seconds after entering the PIN. That's the GTX1650, with the
iGPU switched off. Then, after trying a few more things, I couldn't
even change the PIN (or select "Bullwinkle" secondary profile). But
when that happened, finally windows used the "Diagnose" spinner. And
somehow, I'm running and the Reliability Monitor is not showing any
"NVidia Container" entries for today so far. The 4K monitor is being
driven by the GTX1650 HDMI out.

If I do memtest, it passes.

If I run Linux, it's fine. I've never seen a "similar symptom" while testing Linux on this machine. I could "make a kernel panic" in the past,
via overclocking one of my older single-core machines :-) You can still have boot failures on poorly prepared distros. The worst distros are a sight
to behold (desktop won't start, mouse stops working). But a Ubuntu
or a Linux Mint, is generally well prepared and works fine. And no
symptoms that "smell of hardware level trouble".

I have debugged other problems, via comparison analysis. Run Windows,
get a crash in 20 seconds. Run Linux, get a crash in 20 seconds
(Linux twitching before it dies). This is part of a hardware issue
with the 440BX chipset on Intel. Originally I was blaming Windows,
but when I got the Linux result, then I knew it was hardware and
the address map for memory was somehow not right. Installing 768MB
of memory on 440BX, spells instant trouble (256MB+256MB+256MB).
Slightly less than 768MB, you could run Prime95 for 16 hours with no problem at all (256MB+256MB+128MB+64MB). Very stable, and using
four sticks of RAM too on a single channel bus.

Summary: While I'm running on my Daily Driver profile right now,
I really don't know what will happen next. And with no evidence
of what has changed to stop it, I won't know what to do or where
to go the next time. You'll notice I'm not volunteering to do
a Clean Install (yet).

Paul

I was not going to suggest a Clean Install( yet :) ).
You've mentioned quite a bit about the Nvidia card
- Does the Nvidia graphics card connect via PCI Express 3 x16 slot or
via a single or double 6-pin power connection direct from the power supply?
- Have you considered removing that card from the device to only run
on the onboard video?
Or before complete removal, if possible insert in another mobo slot
or power connector( Note: It's been a while since I've seen a power
supply with a single 6-pin connector though some double connectors allow removal of the 2 pin for a stand-alone single 6-pin)

I'd also look at removing the CPU fan/cooler to determine that heat dissipation is not blocked and also if the fan is operating at intended
rpm for cooling(on old mobos I've seen a few top of cpu cooler fans on
old devices with a bad bearing operating well below 200 RPM(and a lot of
fuzz and dust blocking heat dissipation).

It's been a while since I've seen or heard about Pentium I/II
440BX(which also indicates an older mobo).

Finally, does the device lose user control if booting from a Windows USB
drive and running through some non-destructive tasks(command mode,
diskpart, troubeshooting)?
--
...w¡ñ§±¤ñ
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: alt.comp.os.windows-11

On Tue, 10/20/2026 11:52 PM, ....winston wrote:

I was not going to suggest a Clean Install( yet :) ).
 You've mentioned quite a bit about the Nvidia card
 - Does the Nvidia graphics card connect via PCI Express 3 x16 slot or via a single or double 6-pin power connection direct from the power supply?
 - Have you considered removing that card from the device to only run on the onboard video?
   Or before complete removal, if possible insert in another mobo slot or power connector( Note: It's been a while since I've seen a power supply with a single 6-pin connector though some double connectors allow removal of the 2 pin for a stand-alone single 6-pin)

 I'd also look at removing the CPU fan/cooler to determine that heat dissipation is not blocked and also if the fan is operating at intended rpm for cooling(on old mobos I've seen a few top of cpu cooler fans on old devices with a bad bearing operating well below 200 RPM(and a lot of fuzz and dust blocking heat dissipation).

It's been a while since I've seen or heard about Pentium I/II 440BX(which also indicates an older mobo).

Finally, does the device lose user control if booting from a Windows USB drive and running through some non-destructive tasks(command mode, diskpart, troubeshooting)?

This is a dual boot setup, having Win10 and Win11.

Part of my rescue attempts, were by running on the Win10 side
and the equipment works fine on that side. There's no evidence
to date it is a hardware issue. Seasonic 620W PSU. Eight pin PCIe
Power connector. Vid card in Slot 1. Which means not more than 150W
on the video card via that connector.

The CPU is a 75W one which might run at 130W on turbo. The
cooler is rated for about 150W or so (a Noctua blow-down cooler).
The only reason it got the fancy cooler, is it was a left-over
and replaced the AMD Stealth Cooler that comes in the AMD box.
The fan does pick up speed when compressing files but you can
barely hear the difference, the cooler is that over-the-top.

The Win11 side has been up for a day, on the Daily Driver profile,
so that profile was fixed. The SRTtrail folder of stuff, does not
really hint what kind of repair was attempted. I would expect
the "NVidia component" of the capture was a hint. Whether the
NVidia code is all there, I can't tell. Since at one point
it was broken but running on the second profile there (a relatively
clean profile), it's not necessarily "all driver" as an issue.
It may have been related a bit to the "Nvidia.App-like code".

Normally when this happens, to the system it looks like there was
a local power failure here (as there are no log entries). By
having it fail, multiple times, when attempting to type in
the PIN, that seemed to generate enough breadcrumbs for the
WinRE and automatic recovery to cut in.

That's about all I can say at this point.

I don't think anything is fixed, and I suspect it can and
will behave the same way, if I run on the iGPU long enough.
That NVidia card didn't get put in the machine for fun.
That was part of dealing with this, when it was non-reproducible
and was happening at random.

It hasn't had Linux running on it enough, to conclude anything.
It is just that I've never seen any similar symptom there,
and typically there would be an NVidia binary blob running
the card if doing so. The room runs a particular NVidia
family, so Linux drives can be plugged in anywhere and
be expected to work.

I can run Furmark on the video card and nothing happens. It's
not "load related". The power supply, showed up when the
Zen3 processor and motherboard did, as the previous power
supply did not "like" the fast ramp-up and ramp-down of
the Zen3, and the power supply earned its retirement.
This power supply seems fine with it. As it's a 65W processor
nominally, it's not exactly a "crushing load" on the CPU side.

None of this showed up at first. It was probably three months
before the first symptom showed up. And that was the RealTek
NIC shutting itself down and carrying no traffic, after
around 30 seconds (the time to deciding to drop, being a
constant). Whether that was the containerized driver
at that time, I couldn't figure that out. I tried playing the
driver game, to no good effect.

The machine has WSL2, VirtualBox 6.1.44, VMWare Player, so it
does have a fair amount of junk in the trunk. And I could
run all of those at the same time, so there's nothing to suggest
an architectural limitation on virtualization. The OS is
WIn11 Home, so there is no Hyper-V as such. Windows Defender is the AV.

Paul


--- Synchronet 3.21d-Linux NewsLink 1.2