You did the right thing, removed the watermark, and now a device has stopped working. It feels like the fix broke your PC. It did not. The fix revealed that this device was only ever running because test mode was letting its driver through. This guide explains the evidence and your real options.
The sequence is always the same. Test mode goes off, the PC restarts, and one device, a printer, a USB adapter, a capture card, something specific, shows a yellow warning triangle in Device Manager or simply refuses to work. Nothing else is affected. That device's driver was test-signed. Under normal rules Windows will not load it, and now the normal rules are back. Before you panic or rush to re-enable test mode, read the device's own error message. It will confirm the diagnosis in plain words.
If the error is a different code, this guide is not your situation, and the device has a separate problem that deserves its own diagnosis.
Your goal is a version of this device's driver that carries a trusted signature. Go to the device maker's official support page for your exact model and look for the newest Windows 10 or 11 driver. Also check Settings, Windows Update, View optional updates, where signed drivers for older hardware often wait quietly. If the device is a common type, a printer, a serial or network adapter, a sound device, try letting Windows use its built-in generic driver: in Device Manager choose Update driver, Browse my computer, Let me pick from a list, and see what signed options are offered.
Install the signed driver, restart, and check the device. In a large share of cases this ends the story: device working, test mode off, watermark gone, security restored. It is the only ending where everything is genuinely fixed.
Sometimes the hunt honestly fails: the maker is gone, or never signed a driver for modern Windows. Then your choices are the deliberate ones. Replace the device with a supported model, which ends the problem permanently. Move the device to a spare or dedicated PC where test mode can stay on without exposing your main machine. Or, as a conscious last resort, turn test mode back on with bcdedit /set testsigning on and a restart, understanding exactly which protection you are lowering and why.
What has changed from before is that the choice is now informed. You know which device needs the exception, what the exception costs, and that it should be reviewed when the device retires. That is a completely different position from running test mode by accident.
Searching this problem online surfaces tempting shortcuts: tools promising to sign the driver for you, instructions to disable signature checks entirely with settings like nointegritychecks, or patched driver files from forums. Each one either recreates the same weakness in a worse form or adds a fresh risk from an untrusted source. A disabled integrity check is strictly worse than test mode. A stranger's patched driver is worse still. The honest menu never grows beyond signed driver, replacement, isolation, or a knowing exception.
See every step done live on a real Windows PC in the Technical Anshu video, including the exact command and the restart.
▶️ Watch Full VideoBecause yesterday test mode was on, and Windows was accepting its test-signed driver. Today the normal signature rule is back, so the same unchanged driver is refused with Code 52. The device, the driver and your files are all exactly as they were. Only the permission changed.
Windows does not offer a per-driver exception list for signature enforcement on a normal PC. The rule is system-wide. That is precisely why the practical answers are a signed driver for the device, a different machine for the device, or test mode as a whole-PC exception you accept knowingly.
You restored the exception the device needs, which was a legitimate choice if you made it deliberately. The watermark will return as the visible reminder. Keep a note of which device requires it, keep hunting occasionally for a signed driver, and plan to turn test mode off for good when the device is replaced or retired.