How to Troubleshoot a New PC That Reboots Only During Video Calls
Video-call reboots often come from the interaction between USB devices, drivers, acceleration, power states, and heat rather than one failed part. I’ll show you how to isolate each cause before spending money on replacements.
A new PC that restarts only during video calls can be difficult to diagnose because the call combines several systems at once. Your camera, microphone or headset, USB controller, graphics hardware, network adapter, and power-management settings may all become active together. The reboot may look like a processor or power-supply failure, but replacing parts immediately can waste money.
The efficient approach is to identify what kind of failure you’re seeing, reproduce it safely, and change one variable at a time. Start with the least expensive checks—ports, cables, drivers, and application settings—before moving toward firmware, cooling, or hardware testing.
First, identify what “reboot” means
There’s an important difference between a video-call application closing, Windows showing a blue screen, the display going black, and the entire computer restarting. If the application disappears but the desktop remains usable, investigate the application, camera, audio device, or graphics driver first. If the screen briefly goes black and returns, the graphics driver or display connection may be involved. A complete restart points more strongly toward a system-level fault.
After Windows starts again, open Event Viewer and check Windows Logs > System around the time of the restart. You may see an event from Kernel-Power, commonly event ID 41. That event usually confirms that Windows didn't shut down cleanly; it doesn't identify the original cause. Look for warnings or errors immediately before it, such as display-driver failures, USB errors, disk problems, or unexpected driver resets.
Also check whether Windows created a minidump. A blue-screen crash can restart automatically before you see its message, so temporarily disabling automatic restart can make the next failure more informative: open System Properties, choose Advanced, open Startup and Recovery, and clear Automatically restart. Restore the setting later if you prefer normal automatic recovery.
Check your current software versions: Before changing several settings, note the video-call app version, motherboard BIOS version, graphics and chipset driver versions, and Windows update status. Names and menu locations change, so use the current support pages for your exact motherboard, graphics card, operating system, and call application.
Reproduce the problem with fewer variables
Begin by writing down what happens immediately before the restart. Does it occur when you turn on the camera, join a meeting, unmute, connect a headset, share your screen, or start playing a video? Does it happen with every service or only one application? Does a short audio-only call remain stable?
Run a controlled test rather than repeatedly joining important meetings. Use a test call or the application’s camera and microphone preview. First test without screen sharing. Then test with the camera disabled, followed by a different microphone or headset. If possible, try a second video-call application. This helps separate a device or Windows problem from an application-specific problem.
Disconnect nonessential USB devices while testing: external drives, hubs, capture devices, lighting, controllers, and spare receivers. Keep only the keyboard, mouse, display, and the camera or headset required for the call. A newly built computer may have several devices competing for power or sharing a USB controller, and removing them costs nothing.
Check the camera and USB power path
Cameras can draw more power and create more data traffic when video starts than when they sit idle. A marginal cable, front-panel connection, unpowered hub, or incompatible USB controller can cause the device to disconnect. In severe cases, a driver or system fault can lead to a restart.
Connect the camera directly to a rear motherboard USB port rather than the case’s front panel or an unpowered hub. Try a different port, preferably one with a different USB type or controller if your motherboard provides several. Avoid using a long extension cable during diagnosis. If the camera has a detachable cable, test another suitable data cable; some inexpensive cables provide power but unreliable data.
If the camera works at a lower resolution or frame rate, test that mode temporarily. A stable low-resolution call doesn't prove the camera is defective, but it can indicate a bandwidth, driver, USB power, or processing issue. Check Device Manager for camera and USB-controller errors, and install the camera maker’s current driver or firmware only from its official support source.
Windows may also suspend USB devices to save power. In Power Options, review advanced settings for USB selective suspend. In Device Manager, some USB Root Hub entries include a Power Management tab with an option allowing Windows to turn off the device to save power. Changing this can help isolate a sleep or resume problem, although it may increase idle power use. If the setting makes no difference, return it to its previous value.
Test hardware acceleration and graphics drivers
Video-call applications often use hardware acceleration for camera processing, video decoding, effects, rendering, and screen sharing. That normally reduces processor load, but it also exercises the graphics driver and integrated or discrete GPU in a particular way. A driver conflict can appear only when a call begins or when you share a window.
Look in the call application’s settings for hardware acceleration, graphics acceleration, video effects, or similar options. Disable acceleration temporarily, restart the application, and repeat the same test. If the reboot stops, you’ve found a useful direction—not necessarily a permanent answer. Update the graphics driver from the GPU or system manufacturer, then test acceleration again. If the problem began after a driver update, a known-stable earlier driver may be worth testing instead.
If you have both integrated graphics and a separate graphics card, check which one the application uses. For diagnosis, you can try assigning the application to the other GPU through the operating system’s graphics settings. Screen sharing and virtual backgrounds can place a different load on the GPU than an ordinary camera preview, so test those features separately.
Avoid installing several driver packages or automatic “driver updater” utilities at once. They can make it harder to know which change mattered. Prefer the motherboard, graphics-card, camera, and chipset manufacturers’ support pages, and create a restore point when practical before making a substantial driver change.
Isolate audio devices and network drivers
A microphone or headset can be the trigger even when the camera appears to cause the restart. Test with the motherboard’s basic audio input, then with a USB headset, then with a separate analog headset if available. Don't use a USB hub for the headset during the first tests. Disable audio enhancements, spatial effects, noise suppression, and vendor control-panel effects temporarily.
In the application, select the input and output devices manually instead of relying on “default.” Disconnect Bluetooth audio for one test if you’re using it; Bluetooth adds its own adapter, profile, and driver variables. If one device consistently triggers the reboot, update or reinstall its driver and test another physical port before assuming the device or motherboard is faulty.
Network activity can expose driver problems without being the original cause. A call increases sustained upload and download traffic, while video and audio packets must be processed continuously. Update the Ethernet or Wi-Fi driver from the motherboard or adapter manufacturer. If you’re using Wi-Fi, test a wired connection temporarily. If wired calling is stable, investigate the wireless adapter, antenna placement, driver, and router rather than replacing unrelated components.
You can also test whether the network is merely exposing a software problem by running a local camera preview without joining a call. A reboot during a local preview points toward the camera, USB, graphics, or system. A stable preview followed by a reboot only during network calls gives the network driver and application more weight.
Look at sleep settings, firmware, and temperatures
Some new PCs reboot during calls when the display, USB device, or network adapter changes power state. This can happen when the monitor sleeps, the computer wakes, or Windows transitions between power modes. For testing, use a high-performance or balanced power plan with display and sleep timers set long enough to avoid transitions during a call. Disable sleep only temporarily; it’s a diagnostic step, not automatically the best everyday setting.
Install the motherboard chipset driver and review BIOS updates for fixes related to USB stability, compatibility, memory, or power management. BIOS updates carry some risk if interrupted, so follow the motherboard manufacturer’s exact instructions, use reliable power, and don’t treat an update as a guaranteed solution. Load optimized defaults if you’ve changed overclocking, undervolting, memory tuning, or custom power limits. Enable memory profiles again only after the system is stable at default settings.
Monitor processor and graphics temperatures while running a controlled call. A call alone shouldn't be treated as a definitive stress test, but camera effects, screen sharing, and browser video can change the load. Use a reputable hardware-monitoring tool and watch for rapidly rising temperatures, fan failures, or thermal-throttle warnings. Confirm that the CPU cooler is mounted correctly, its fan is connected, the case fans are operating, and protective film was removed from the cooler base.
If the reboot happens only when the discrete GPU becomes active, check its power connectors and seating with the computer turned off and unplugged. Don't force a connector, mix modular power-supply cables from different brands, or leave a partly inserted cable in place.
When to test memory and power
Once software and peripherals are reasonably isolated, test system memory at default settings. Run the operating system’s memory diagnostic or a reputable bootable memory test, ideally for more than a quick pass if failures are intermittent. Test one memory module at a time in the motherboard’s recommended slot if the results are unclear. A new system can have a faulty module, an incorrectly seated module, or a memory profile that is unstable even though the advertised speed is supported in principle.
Power problems are possible, especially if the computer restarts when the GPU, CPU, USB devices, and network activity overlap. Check that the power supply has adequate capacity for the installed components and that every required motherboard and graphics power connector is attached. A call-only reboot doesn't by itself prove the power supply is inadequate, because software and USB faults can produce the same symptom.
Don’t open the power supply or attempt internal repairs. If the PC also reboots during games, rendering, or other heavy workloads, or if you notice burning smells, unusual electrical noise, heat at a connector, or visible damage, stop using it and seek qualified service or the manufacturer’s support. Safety concerns take priority over further testing.
A sensible order for the fix
Keep a short change log: record the device connected, application setting, driver version, and result of each test. If disabling acceleration fixes the problem, update the graphics driver and re-enable the feature as a confirmation test. If moving the camera to a rear USB port fixes it, leave the hub or front-panel connection out of the setup until you can test its cable and power path. If a wired network connection fixes the issue, concentrate on the Wi-Fi adapter and its driver.
The lowest-cost permanent solution may be as simple as a different USB port, a direct connection instead of a hub, a clean driver installation, or leaving a problematic enhancement disabled. Continue toward memory, BIOS, temperature, and power testing only when the earlier results justify it. That sequence preserves your time, avoids unnecessary purchases, and gives you useful evidence if a component does eventually need warranty replacement.
After the PC remains stable through several controlled calls, test a normal meeting with the camera, microphone, screen sharing, and usual peripherals restored one at a time. A successful repair isn't just a computer that survives one call; it’s a repeatable setup in which you know which devices and settings are working together reliably.