Windows not starting after a reboot, only works when forced via BIOS
Windows not starting after a reboot, only works when forced via BIOS
Hello everyone,
I'm performing an upgrade and rebuild of my PC, installing a new motherboard, CPU, graphics card, and RAM.
Updated parts list:
Motherboard: ASUS Z790 Gaming Wifi7
CPU: i9-14900k
GPU: ASUS GeForce 5070 OC Tuf gaming
RAM: Corsair DDR5 6000mhz 2x16gb
Previous components:
NZXT Kraken 360
M.2 SSD
SSD
HDD
etc.
Current behavior:
I ran a clean Windows installation on the M.2 drive, which is now my boot device. I accessed it via the BIOS menu and selected the M.2 slot. After booting, I proceeded to install all my software, run tests, and update Windows.
Main concerns:
1. CPU temperatures rose significantly during stress tests, reaching 100°C. The default clock is set at 5.9GHz at 1.34V. I tested it at both BIOS default and Intel Tuning optimized settings, as well as at 5.5GHz with similar outcomes. The fans are operating at full speed and appear normal. However, the BIOS doesn't detect them because they're routed through the NZXT fan hub and into a USB header on the motherboard instead of the CPU fan header. It seems the fans won't increase speed unless NZXT Cam is active, which could be an issue later.
2. Restarting Windows for updates or using the software restart causes the system to freeze, display remains off, but hardware continues functioning.
3. The system boots into BIOS every time due to a forced shutdown during the previous boot.
4. Occasionally, I've experienced inconsistent behavior—booting straight into Windows after removing one RAM stick or another drive—but it doesn't resolve consistently (e.g., removing drives and one RAM still causes boot problems).
I've repeated applying thermal paste three times, reset the BIOS to default settings, and placed the unit in a bread box with minimal components.
Next steps:
I plan to perform another fresh Windows 10 installation from the boot media.
Note: I also observed that the CPU socket has several visible pins at the top. Is this typical or a defect that might be contributing to these issues?
Error logs from Event Viewer during restart attempts:
"The server could not bind to the transport Device\NetBT_Tcpip_{C6D72FB2-0F6F-4544-A361-E80C30781EE3} because another computer on the network has the same name. The server could not start."
"The IPv4 TCP/IP interface with index 17 failed to bind to its provider."
Any advice or suggestions would be appreciated.
You might consider updating the BIOS to the newest release, though this raises some worries. I also observed that the CPU socket has several visible pins at the top—this is typical or a possible defect contributing to the problems? If the device arrives in this condition (unopened), please initiate a return and avoid attempting repairs on the bent pins.
I bet heavily on those pins being responsible. The reason is clear—any bent pin can lead to a range of unpredictable results, or even consistent but surprising outcomes. With several bent pins present, it’s hard to say if the issue came from your action or was already there. The pin bed on 12th-14th Gen boards is significantly more fragile compared to older generations, since the socket size stays the same while around 500 extra pins fit in the same space. This makes them much more prone to bending. You must handle the removal of the socket protector with extreme caution, especially until the CPU is properly installed. It’s likely you’re about 50% more likely than with older LGA sockets to accidentally harm the pin bed on LGA 1700 compared to LGA 1200 or earlier Intel models. Recently, I’ve seen two new boards—one from Amazon and one from Newegg—both reported with bent pins out of the box. I’d recommend replacing or refunding them right away.
NetBT_Tcpip i think is netbios over tcpip
before registering a name it will ask the network it any machine is using that name. I have seen old cases where a machine that has more than one network connections will register the name on one adapter then see the announcement from the second adaptor on the same machine then get this type of failure. I think there is a windows method to prevent this but it can be bypassed and who know what would happen during a plug and play setup of a second device. It used to be that the slowest device would not be used. you could work around it in various ways but just for testing you would use the wireless device and unplug any hardwired network cable and see if the problem goes away.
for the problem during a restart, windows should not complete the restart if it thinks it is going to loose some data. this happens if windows tries to flush a buffer to disk but does not get a response. for this case you would google "how to make windows use verbose logon or logoff messages."
then make the registry or app changes and the next time windows should tell you what it is waiting for.
I have seen this problem with some 3rd party network attached storage, bugs in ssd firmware and some firmware in older drives.
(cases that require you to turn off drive lazy writes to get proper shuddowns)
in these cases the screen goes black and it looks like it shut down and did not restart. You hit the power button and it forces a dirty shutdown, the system reboots and runs chkdsk on the drive and puts a warning in the event log. in reality, windows was waiting for a signal before completing the shutdown and the user forced a dirty shutdown.