Update 6: ROG STRIX B550-F Gaming Wifi II - Windows 11 system locking up on login/RDP (Solved)

Anonymous
2024-12-17T04:56:21+00:00

Update 6:

It's the rule of the road when you discover the fix of your issue that you post it so others can find it.

Problem: System would lock up on login, whether by mouse and keyboard or RDP. Symptoms included:

  • RDP would randomly disconnect over time. Reconnection would timeout.
  • Screen would turn black or would no longer respond to the monitor connection
  • Attempting to log back in would fail or cause it to spin forever
  • Random USB devices like mouse/keyboard would stop working

Fixes:

  • Updated motherboard BIOS to latest (should have updated after I got it to POST)
  • Ran the driver verifier:

https://answers.microsoft.com/en-us/windows/forum/all/driver-verifier-tracking-down-a-mis-behaving/f5cb4faf-556b-4b6d-95b3-c48669e4c983

After running the driver verifier, it would BSOD on Asio3.sys

Asio3.sys is part of the AI Suite, so I had to remove it: https://rog-forum.asus.com/t5/armoury-crate/asio3-sys/td-p/906063

Lessons learned:

  1. Update your Mobo BIOS immediately after you get it to POST, before you install the OS.
  2. Don't install all the software that comes with your Mobo

You can see the saga I went through below.

Update 1:

Updating the issue since I am still digging into why this is happening and I just got new info.

So I started my machine and signed in with mouse/keyboard instead of RDP because RDP would crash in anywhere from 10 hours or less than one hour. I wanted to backup the data on the machine and since there is terabytes of data to copy, freefilesync was taking a while.

I windows key + L to lock the machine and when I come back from lunch I log in the check the machine.

The keyboard is not responding but the mouse was. I notice that the num lock light on the keyboard is off and won't turn back on after repeatedly pressing it. I unplug the keyboard and plug it back in and it still doesn't work. The machine progressively becomes less responsive and more and more programs lock up until nothing responds to mouse input (not even my openshell based desktop).

As mentioned below, the day before I woke up to a DRIVER_POWER_STATE_FAILURE BSOD that analyzing the MiniDump in winDBG revealed happened in UsbHub3.sys.

Before this most recent crash, I disabled USB selective suspend setting in advanced power options and I got most of the devices in the Device Manager (under Universal Serial Bus controllers) that use UsbHub3.sys to disable "Allow Computer to turn off device to save power". I just saw I missed one.

I will uncheck that one and soak test it to see if it fixes the problem. If anybody has any other suggestions on what to check, let me know.

Update 2:

The disconnection to RDP is still happening after the SOAK test as is the freezing up, only the freezing up is different this time.

Changes I made:

-Disabled "Allow Computer to turn off device to save power" on all devices in the Device Manager using the UsbHub3.sys.

-Decrypted the drives so could update the BIOS

-Updated the motherboard bios.

The computer seemed to be working fine after the bios update. I say this because before the bios update whenever signed it via mouse/keyboard and then logged into the same machine via RDP, the RDP login would stall and I would have to disconnect and reconnect to get RDP to work. Now, I can fairly seamlessly jump back and forth between RDP and mouse/keyboard without it locking up.

I was letting it soak test and about 8 hours later my RDP session become unresponsive.

What's interesting is that I went to the mouse and keyboard to sign in directly to the fileserver after the RDP session gave out, I turned the monitor back on and it wasn't coming getting an HDMI signal. I was wiggling the mouse and pressing buttons on the keyboard and the monitor got no signal.

Could this be a sign of a bad GPU?

Update 3:

I restarted my desktop after update 2 to see if I could reproduce the issue.

I woke up this morning, tried to RDP to the machine and got a "Your Remote Desktop Services session has ended" notification. I then tried to sign into the server via mouse/keyboard and after punching in the password, the screen went black. Then the keyboard went unresponsive where the numlock wouldn't respond. Weirdly, even with the screen going black, the share drives still worked.

I am thinking this may be a GPU issue. Maybe driver or hardware? How would I verify?

Update 4:

Restarted the desktop again. Signed via RDP again. Went to lunch and came back. Once again, RDP session conked out.

This time though, I went to the mouse/keyboard and pressed the up button to bring up the log in screen. The time slid off the screen but the mouse is just spinning in a wait state. I press the up button again and the time returns. I press again to try to log in but the login screen doesn't come up.

Maybe the hard disk is messed up?

Update 5:

I ran chkdsk C: /v /r /x

Here are the results from the Event Viewer:


Checking file system on C:

The type of the file system is NTFS.

A disk check has been scheduled.

Windows will now check the disk.                         

Stage 1: Examining basic file system structure ...

  287232 file records processed.                                                         

File verification completed.

 Phase duration (File record verification): 1.70 seconds.

  12070 large file records processed.                                    

 Phase duration (Orphan file record recovery): 5.17 milliseconds.

  0 bad file records processed.                                      

 Phase duration (Bad file record checking): 1.21 milliseconds.

Stage 2: Examining file name linkage ...

  226 reparse records processed.                                       

  400566 index entries processed.                                                        

Index verification completed.

 Phase duration (Index verification): 4.00 seconds.

  0 unindexed files scanned.                                         

 Phase duration (Orphan reconnection): 153.38 milliseconds.

  0 unindexed files recovered to lost and found.                     

 Phase duration (Orphan recovery to lost and found): 524.13 milliseconds.

  226 reparse records processed.                                       

 Phase duration (Reparse point and Object ID verification): 3.88 milliseconds.

Stage 3: Examining security descriptors ...

Cleaning up 1119 unused index entries from index $SII of file 0x9.

Cleaning up 1119 unused index entries from index $SDH of file 0x9.

Cleaning up 1119 unused security descriptors.

Security descriptor verification completed.

 Phase duration (Security descriptor verification): 19.14 milliseconds.

  56668 data files processed.                                            

 Phase duration (Data attribute verification): 1.26 milliseconds.

CHKDSK is verifying Usn Journal...

  37385592 USN bytes processed.                                                            

Usn Journal verification completed.

 Phase duration (USN journal verification): 81.51 milliseconds.

Stage 4: Looking for bad clusters in user file data ...

  287216 files processed.                                                                

File data verification completed.

 Phase duration (User file recovery): 1.48 minutes.

Stage 5: Looking for bad, free clusters ...

  226696705 free clusters processed.                                                        

Free space verification is complete.

 Phase duration (Free space recovery): 1.53 minutes.

Windows has scanned the file system and found no problems.

No further action is required.

 975983615 KB total disk space.

  68615748 KB in 218453 files.

    156732 KB in 56669 indexes.

         0 KB in bad sectors.

    424311 KB in use by the system.

     65536 KB occupied by the log file.

 906786824 KB available on disk.

      4096 bytes in each allocation unit.

 243995903 total allocation units on disk.

 226696706 allocation units available on disk.

Total duration: 3.12 minutes (187778 ms).

Internal Info:

00 62 04 00 17 2f 04 00 94 ed 07 00 00 00 00 00  .b.../..........

73 00 00 00 6f 00 00 00 00 00 00 00 00 00 00 00  s...o...........


After the restart, I tried to RDP. Since I updated the MoBo bios until now, signing in via RDP didn't hiccup. Now I had to disconnect/reconnect about 3/4 times for the RDP session to go through with either screen freezes or black screens coming up.

I checked the Even Viewer and see a handful of these errors:

WMI : SELECT InstanceName, VideoOutputTechnology FROM WmiMonitorConnectionParams

Error 0x80070005 occurred while verifying known folder {f1b32785-6fba-4fcf-9d55-7b8e7f157091} with path 'C:\WINDOWS\system32\config\systemprofile\AppData\Local'.

I am guessing this means something is causing an query to fail? Maybe my Windows 11 install is bad?

***The original issue when I thought it was RDP log ins that was causing the issue below***

Hello,

I have a strange issue I am dealing with where RDP disconnects randomly and attempting to log in directly to the home file server via mouse and keyboard after the RDP failure will cause the log in to spin around indefinitely.

The home file server that I am trying to RDP to and keeps messing up on is running Window 11 Pro. The computer I am RDP'ing from is running Window 10 Pro. The home file server was assembled two days ago. The previous file server was running Windows 10 Pro and ran just fine for 5 years.

The most consistent issue is I would sign in via RDP, and after a few hours (sometimes less than an hour) it would randomly disconnect. I would try to reconnect to RDP and it would fail. I would go up to the machine afterwards to try to sign in directly, and then the login screen would just spin forever (or at least 15+ minutes when I did a hard restart with the power button).

Other symptoms include:

-If I sign in directly to the machine and then try to RDP to it, the first RDP log in may lock up. I X out of RDP and try again and it works.

-If RDP randomly disconnects and I try to psychically restart the file server, it will also spin indefinitely.

-When I thought it was fine and left it running for while, I signed into the home server and I got a blue screen of death with a DRIVER_POWER_STATE_FAILURE. The minidump reported the issue was caused by UsbHub3.sys.

-I have drives I am sharing over LAN. I notice that after the RDP conks out, the drives start having jittery right speed.

***Move from Windows / Windows 11 / Performance and system failures***

Windows for business | Windows Client for IT Pros | User experience | Remote desktop clients

Locked Question. This question was migrated from the Microsoft Support Community. You can vote on whether it's helpful, but you can't add comments or replies or follow the question. To protect privacy, user profiles for migrated questions are anonymized.

0 comments No comments
{count} votes

5 answers

Sort by: Most helpful
  1. Anonymous
    2024-12-17T19:48:13+00:00

    More background info:

    1. This is my first attempt to build a computer and it has not been going well.
    2. This my second attempt at this build. The first time I attempted a mini-ITX in a NAS enclosure.
    3. The problems with the Mini-ITX is that it kept randomly BSOD'ing and the space was so cramped that is was hard to adjust anything. Eventually I just decided to switch to a ATX case.
    4. I asked for help from friends in building the new one and they noticed that I applied more than double the recommend amount of thermal paste. They suspect that this meant it wasn't getting good contact with the heaksink and that may have caused the BSODs
    5. I changed out the Motherboard, RAM, and Case, I kept the CPU, SSD, HDDs
    6. The CPU is a AMD Ryzen 6 5500GT which has integrated graphics. If there's a problem with the CPU that means there's a problem with the GPU.
    0 comments No comments
  2. Anonymous
    2024-12-19T06:49:44+00:00

    Updated question again after more adjustments were made and more symptoms came up.

    0 comments No comments
  3. Anonymous
    2024-12-19T18:20:02+00:00

    Updated question again with more info after more investigation.

    0 comments No comments
  4. Anonymous
    2024-12-19T23:03:10+00:00

    Updating for the 4th time with more info.

    0 comments No comments
  5. Anonymous
    2024-12-20T01:53:36+00:00

    Got another update after running chkdsk

    0 comments No comments