Cannot find Script file C:\Windows\run.vbs [Solved 2026]

"Cannot find Script file C:\Windows\run.vbs" means the Windows logon process is trying to run a script that no longer exists. To fix it, open the Registry Editor — press Ctrl + Alt + Del works even on a black screen — go to HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon, set Shell to explorer.exe and Userinit to C:\Windows\system32\userinit.exe, (the trailing comma matters). The steps are identical on Windows 11 and Windows 10.

Here is the part most pages never tell you: Windows has never shipped a file called run.vbs. This error is not a broken system file. It is the leftover fingerprint of a VBScript worm that your antivirus already deleted — the registry still points at the corpse. Seeing this box usually means your antivirus won, and Windows just needs to be told the fight is over.

The $180 Black Screen

Jake runs a small mobile phone shop, and people keep bringing him laptops because a shop that fixes phones must surely fix computers. Last Tuesday a regular customer carried in her son's laptop. It powered on, accepted the password — and then showed nothing but a black screen and one small white error box: Can not find script file "C:\Windows\run.vbs".

She had already been to a repair chain. Their quote: $180, "Windows is corrupted, needs a full reinstall, and you will lose whatever is not backed up." The boy's school project was on that laptop. No backup, of course.

Jake called Ethan, mostly to ask how to break the bad news gently.

"Don't reinstall anything," Ethan said. "That error is one registry line. Four minutes. And the machine is probably cleaner right now than it was last month."

"Cleaner? It doesn't even show a desktop."

"Because the note that tells Windows to start the desktop got vandalized by a worm, and then the antivirus shot the worm. We just rewrite the note. Watch."

Four minutes later the desktop was back, school project intact. This guide is the long version of those four minutes — both variants of the error, the black-screen rescue when you cannot click anything, the cleanup that stops it returning, and why this whole class of error is quietly going extinct as Microsoft retires VBScript.

One Question Picks Your Route: Can You See Your Desktop?

Everything about this fix depends on one thing: after you dismiss the error box, do your icons and taskbar appear?

The error text varies slightly — "Can not find script file", "Cannot find script file", sometimes a different name like servieca.vbs or help.vbs instead of run.vbs. The mechanics and the fix are the same for all of them: a script launcher is being told to run a file that an antivirus already removed.

What Actually Happened to Your PC

A .vbs file is a VBScript — a small text file of commands that Windows can execute through a built-in program called wscript.exe (Windows Script Host). VBScript has been part of Windows since the 1990s, and for most of that time it was a favorite tool of malware writers, because a script needs no installer, no compiler and no permission prompt to run.

Around 2014–2016, a family of VBScript worms — best known by names like Jenxcus and Houdini — spread mostly through USB flash drives. Once on a machine, the worm copied a script such as run.vbs into C:\Windows and then edited the registry keys that control what starts at logon, so the script would run every single time anyone signed in. Copies of the same trick still circulate today on infected USB sticks and cracked-software downloads, which is why a 2014-era worm still generates this error on Windows 11 in 2026.

The two registry values it tampers with live at HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon:

• Userinit — the program Windows runs the moment you sign in. Factory value: C:\Windows\system32\userinit.exe, — yes, with a trailing comma. The worm appends itself: C:\Windows\system32\userinit.exe,wscript C:\Windows\run.vbs. Result: desktop loads, error pops.
• Shell — the program that is your desktop. Factory value: explorer.exe. Some variants replace it with wscript.exe C:\Windows\run.vbs. Result: the script is gone, explorer.exe is never started — error box on a black screen.

Then your antivirus caught up. Windows Defender, or whatever was installed, detected run.vbs and deleted it — correctly. But antivirus products are cautious about editing Winlogon registry values, because a wrong edit there can make a PC unbootable. So the pointer stayed behind. Every logon, Windows obediently tries to run a file that no longer exists, and wscript.exe reports exactly that: it cannot find the script file.

Where our 2016 article got it wrong

This post was first published in March 2016, and the original version claimed the virus "deletes .vbs files stored in System32", as if run.vbs were a legitimate Windows file that went missing. That was wrong, and it is worth being precise about why: run.vbs was never a Windows file — it was the malware itself, and the thing that deleted it was your antivirus doing its job. The original also only fixed the Userinit value, which repairs the pop-up variant but does nothing for the black-screen variant caused by a hijacked Shell value. This rewrite fixes both, and adds the rescue path for when you cannot reach a desktop at all.

Route 1 — Desktop Loads: Fix the Registry in Two Minutes

These steps are exactly the same on Windows 11 and Windows 10 — the Registry Editor has not changed in decades. You need an administrator account.

Step 1 — Open the Registry Editor

Press Win + R to open the Run box — the small "type a command" window Windows has had since forever — type regedit and press Enter. Say Yes to the permission prompt. Regedit looks like File Explorer, but the "folders" (keys) hold settings instead of files.

Step 2 — Jump to the Winlogon key

Click the address bar at the top of regedit, paste this, and press Enter:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon

The address bar was added in Windows 10 1703; nobody should be expanding that tree by hand anymore. Note it is "Windows NT", not "Windows" — both keys exist and the wrong one does not contain Winlogon.

Step 3 — Restore Userinit

In the right-hand pane, double-click Userinit. If its data contains wscript, run.vbs, or anything beyond the factory value, replace the whole line with exactly:

C:\Windows\system32\userinit.exe,

Type the trailing comma. It is the separator Windows uses for this multi-program value, it ships from the factory with the comma in place, and leaving it off is the most common way people turn a two-minute fix into a lock-screen loop. Remove every trace of wscript and run.vbs from the line, then click OK.

Step 4 — Restore Shell

Still in Winlogon, double-click Shell. The data must be exactly:

explorer.exe

Nothing before it, nothing after it. If yours says anything else — extra commas, wscript, a path to a .vbs or .bat file — replace it all with the single word above and click OK.

Step 5 — Check the per-user copy too

Newer worm variants hide a second copy where fewer people look. Paste this into the regedit address bar:

HKEY_CURRENT_USER\Software\Microsoft\Windows NT\CurrentVersion\Winlogon

On a healthy PC this key usually has no Shell value at all — the machine-wide one applies. If you find a Shell value here pointing at a script, right-click it and delete that value (just the value, not the key). If several people use the PC, check while signed in to each account, because HKEY_CURRENT_USER is per-user.

Windows on a different drive letter?

If Windows lives on D: or F: — common on self-built PCs and some OEM recovery setups — use that letter in the Userinit path: F:\Windows\system32\userinit.exe, and so on. Not sure? Press Win + R, type cmd, press Enter, then type echo %WINDIR% — it prints the real Windows folder path.

Restart. The error should be gone. Now go straight to the cleanup section — the Winlogon values are almost never the worm's only leftover.

Route 2 — Black Screen: Repair Without a Desktop

The black screen looks terminal, but remember what it is: Windows signed you in successfully and then started nothing. Everything underneath still works — including Task Manager.

The Task Manager rescue (works in 90% of cases)

Press Ctrl + Alt + Del on the black screen and choose Task Manager. This screen is drawn by the system itself, not by explorer.exe, so it appears even when the desktop cannot.

In Task Manager, find Run new task: on Windows 11 it is a button at the top; on Windows 10 it is under File → Run new task (click More details first if you see the compact view). Type regedit, tick the box Create this task with administrative privileges, and press Enter.

Now do the exact Route 1 edits: Shell back to explorer.exe, Userinit back to C:\Windows\system32\userinit.exe, — then restart from the Ctrl+Alt+Del screen's power icon. If you want your desktop back immediately without restarting, use Run new task once more and start explorer.exe. That command launches the same program behind your desktop, taskbar and file windows — if that name is new to you, here is where File Explorer lives in Windows and what it actually is.

Edge cases: tablets, remote sessions and Home edition

On a Windows tablet with no keyboard, hold the Windows button and the power button together — that is the hardware Ctrl+Alt+Del — and the same menu with Task Manager appears. In a Remote Desktop session, Ctrl+Alt+Del goes to your local PC, not the remote one; press Ctrl + Alt + End instead. And one reassurance: everything in this guide works on Windows Home. The fix needs only regedit, which every edition includes — nothing here requires the Group Policy Editor that Home famously lacks.

If Task Manager is blocked: Safe Mode

Some infections disable Task Manager before dying. Plan B: on the black screen press Ctrl + Alt + Del, hold Shift, and click the power icon → Restart. The PC reboots into a blue recovery menu: choose Troubleshoot → Advanced options → Startup Settings → Restart, then press 4 for Safe Mode. Safe Mode starts explorer.exe directly and ignores most startup hijacks, so you get a desktop — run regedit from there and make the Route 1 edits.

The hard case: no logon at all (offline registry edit)

If a botched Userinit edit has you stuck in a lock-screen loop, you can edit the registry from the recovery environment without signing in. Force the recovery menu by interrupting boot three times (power off at the Windows logo, twice), then Troubleshoot → Advanced options → Command Prompt. Type regedit. In this offline regedit, click HKEY_LOCAL_MACHINE, then File → Load Hive, and open C:\Windows\System32\config\SOFTWARE (in recovery, your Windows drive sometimes shows as D: — check both). Name the loaded hive TEMP, fix Shell and Userinit under TEMP\Microsoft\Windows NT\CurrentVersion\Winlogon, then select TEMP and use File → Unload Hive before restarting. This is the deepest tool in this guide — if you are here, type slowly.

Clean Out the Leftovers So It Never Comes Back

The Winlogon values are the worm's main hook, but rarely its only one. Five minutes here saves you seeing the error again next month.

Run keys — the other autostart list

In regedit, check both of these keys and delete any value whose data mentions wscript, .vbs, or a script name you do not recognize:

• HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run
• HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Run

Leave entries you recognize (OneDrive, your antivirus, printer software) alone. When in doubt, search the value's file path online before deleting.

Startup folder and Task Scheduler

Press Win + R, type shell:startup, press Enter — delete any .vbs or strange shortcut in the folder that opens. Repeat with shell:common startup for the all-users folder. Then open Task Scheduler (search it in Start), click Task Scheduler Library, and delete any task that runs wscript or a .vbs file — this is the classic cause of the error appearing at random times instead of at logon.

The USB sticks that started it

These worms spread by copying themselves to every flash drive they touch, hiding your real folders and replacing them with shortcut files that launch the script. Plug each stick you own into the cleaned PC, let your antivirus scan it, then delete any .vbs files and shortcut copies and unhide your folders. If a stick refuses to let you copy your files back off it afterwards, that is usually leftover attribute damage, not a dead drive — the fixes in our cannot copy file to destination guide cover it. Worm copies and their duplicated folders can also quietly swallow gigabytes, so once the stick is clean, a quick pass through Settings → System → Storage on the PC shows whether anything oversized was left behind.

The backup lesson hiding in this story

The part of Jake's Tuesday that should worry you is not the worm — it is the school project that existed in exactly one place. The repair chain's $180 quote was scary precisely because "you will lose whatever is not backed up" was true. This error happened to be reversible; a ransomware script traveling the same USB route would not have been. A $40 external drive plus Windows File History, or any cloud backup running on autopilot, turns every future scare like this from a crisis into an inconvenience. Ethan's rule for Jake's shop: any file you would pay $180 to get back is a file you should have two copies of — and it costs far less than $180 to make that true today.

Jake's follow-up question was the practical one: "The kid's USB stick goes back to a school computer lab tomorrow. Does this start all over again?" Quite possibly — which is why the scan below, on both the PC and the stick, is not optional.

Confirm the Infection Is Actually Gone

You have removed the pointers; now verify nothing is left writing new ones.

Run a Microsoft Defender Offline scan

A normal quick scan is not enough here. Open Windows Security → Virus & threat protection → Scan options, choose Microsoft Defender Offline scan, and let the PC reboot into it. This scan runs before Windows fully starts, so malware that hides while the system is running has nowhere to hide. It takes about 15 minutes. The built-in Defender is genuinely good in 2026; a paid antivirus is a reasonable extra layer for a business machine like Jake's shop PC that meets strangers' USB sticks every week, but it is not required for this fix.

Check Windows system files with SFC

To be clear about what this does and does not do: SFC cannot "restore" run.vbs, because run.vbs was never a Windows file. What it can do is verify the worm did not damage anything that is a Windows file. Right-click Start, open Terminal (Admin) on Windows 11 or Windows PowerShell (Admin) on Windows 10, and run:

sfc /scannow

SFC (System File Checker) compares every protected system file against a known-good copy and repairs mismatches. If it reports unfixable errors, run DISM /Online /Cleanup-Image /RestoreHealth — it repairs the reference copy SFC compares against — then run sfc /scannow once more.

Reading a suspicious script safely

If you found a .vbs file and want to know what it did before you delete it, do not double-click it — that runs it. Right-click → Show more options → Edit on Windows 11 (the condensed right-click menu hides the old entries) opens it as harmless text in Notepad. Script code is unreadable to most people, and pasting malware into a cloud chatbot means uploading it to someone else's server. A better option in 2026: an AI model running entirely on your own PC can read the script offline — our guide to running Google's Gemma 4 locally on Windows, free and private, shows the setup in about ten minutes, and a pasted script with the question "what does this do?" gets you a plain-English answer without the file ever leaving your machine.

One detail from the registry steps deserves repeating on its own: the trailing comma at the end of the Userinit value is not a typo. Retype that value without the comma and the next restart lands in an instant sign-in loop — a strictly worse position than the error you started with. That exact situation is what the offline hive edit in Route 2 is there to recover from, so if you are editing Winlogon values by hand, copy them character for character.

The Quiet Death of VBScript — Why This Error Is Going Extinct

There is a bigger story behind this little error box. Microsoft is removing VBScript from Windows entirely — in slow motion, so thirty years of business scripts get time to migrate.

• Now (Windows 11 24H2 and 25H2): VBScript is no longer a fixed part of Windows. It ships as a Feature on Demand — an optional component — still enabled by default, which is why wscript.exe still ran the hijack on our test machines.
• Around 2027: Microsoft's stated plan flips the default — VBScript will be disabled unless you switch it on yourself under Settings → System → Optional features.
• Later, date unannounced: removed from Windows completely.

Ethan's opinion, for the record: good riddance. VBScript powered two decades of USB worms, fake-invoice email attachments and tech-support scams, and its replacement, PowerShell, logs what scripts do and can require them to be signed. If you have a legitimate old .vbs that your business depends on — label printers and stock-report scripts from the 2000s are common in shops like Jake's — it will keep working today, but treat the 2027 default-off date as your migration deadline, not a rumor to ignore.

What actually breaks when the default flips? Anything still launched through wscript.exe or cscript.exe: logon scripts on old office networks, .vbs shortcuts that print labels or map drives, installer helpers inside legacy software, and half the "copy this script to fix Windows" advice written before 2020 — including, frankly, a few early posts on this site. The scripts do not error gracefully, either; they simply stop running, which on an unattended shop PC can look like a mystery failure. If a machine you manage still leans on .vbs anywhere, write the PowerShell replacement this year, while the old and new can run side by side.

Two practical consequences for this error. First, if you disable the VBScript optional feature today on 24H2 or newer, this entire malware class simply cannot execute on your machine — a free immunization most articles never mention. Second, a related honest note for Windows 10 holdouts: Windows 10 support ended October 14, 2025, so without enrolling in Microsoft's Extended Security Updates (free options exist, and coverage now runs to October 2027) a Windows 10 PC no longer receives fixes for exactly the kind of holes these worms crawl through. Fix the registry either way — but plan the upgrade.

FAQ: Cannot Find Script File run.vbs

Is run.vbs a real Windows system file?

No. No version of Windows has ever shipped a file called C:\Windows\run.vbs. If your PC references it, malware put that reference there. The error means the malicious script has already been deleted — almost always by your antivirus — while its registry pointer survived.

Can I just click OK and ignore the run.vbs error?

If your desktop loads, clicking OK costs you nothing today — but you are leaving hijacked logon values in the registry, and anything that later recreates a file at that path runs automatically with your sign-in. The proper fix takes two minutes. Do it.

What should the Userinit registry value be?

Exactly C:\Windows\system32\userinit.exe, — including the trailing comma, with the drive letter adjusted only if Windows is installed somewhere other than C:. It lives at HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon.

What should the Shell registry value be?

Exactly explorer.exe — one word, no path, no comma. That is the factory value in every version of Windows from XP through Windows 11 25H2. The per-user Winlogon key under HKEY_CURRENT_USER normally has no Shell value at all; if one appears there pointing at a script, delete the value.

Do I need to recreate the run.vbs file?

No — and the popular forum advice to create a blank run.vbs in C:\Windows is actively bad. It silences the error while leaving your logon pointed at an attacker-controlled path: anything that later writes real code into that file runs at every sign-in. Fix the registry values instead; never plant the decoy file.

Which virus causes the run.vbs error?

Usually a VBScript worm of the Jenxcus/Houdini family (Microsoft names include VBS/Jenxcus), which spread through USB flash drives and edited the Winlogon Userinit and Shell values to launch itself at every logon. Variants use other filenames — servieca.vbs, help.vbs — but the mechanism and the fix are identical.

Does this error mean my PC is still infected?

Usually the opposite — the script itself is gone, which is why Windows cannot find it. But the worm may have left other autostart entries, and the USB stick that delivered it may still be infected. Run a Microsoft Defender Offline scan and check the Run keys, startup folders and Task Scheduler as shown above before declaring victory.

Why does the error come back after I fix it?

Reinfection, almost always from a USB drive that was never cleaned, or a second autostart entry you missed — typically a scheduled task. Scan every flash drive on the cleaned PC, then recheck the two Run keys, shell:startup, and Task Scheduler Library for anything running wscript or a .vbs file.

Will a Windows reset or reinstall fix the run.vbs error?

Yes, in the way that demolishing a house fixes a squeaky door. A reset costs hours and risks files; the registry fix takes minutes and risks nothing when typed carefully. Reserve reinstalling for machines with deeper damage that SFC and a Defender Offline scan cannot clear.

Are the steps different on Windows 11 and Windows 10?

The registry fix is identical — same key, same two values, same data. Only the small things differ: Windows 11 puts Run new task as a button at the top of Task Manager while Windows 10 hides it under the File menu, and Windows 11 hides the right-click Edit option for scripts behind Show more options.

Can wscript.exe be deleted to stop the error?

Do not delete it — wscript.exe is a legitimate Windows component, and SFC would restore it anyway. If you want script execution gone, do it the supported way: on Windows 11 24H2 or newer, remove the VBSCRIPT entry under Settings, System, Optional features. Same immunity, fully reversible.

Is VBScript being removed from Windows?

Yes, in phases. Since Windows 11 24H2 it is an optional Feature on Demand, still enabled by default as of August 2026. Microsoft plans to disable it by default around 2027, then remove it entirely in a later release. Old .vbs-based advice — and .vbs malware — is on borrowed time.

What if my Windows is installed on a drive other than C?

Use your real drive letter in the Userinit data — for example F:\Windows\system32\userinit.exe, — and keep the trailing comma. Find the correct letter by running echo %WINDIR% in Command Prompt. The Shell value stays explorer.exe regardless of drive, because it carries no path.

Can a local AI help me read a suspicious script?

Yes, and it is the private way to do it: a model running on your own PC can explain a script line by line without the file ever leaving your machine. See our beginner walkthrough for running Google's Gemma AI locally on Windows for free — paste the script, ask what it does, delete it with confidence.

Keep Reading

Revision note. Originally published March 14, 2016. Rewritten August 12, 2026, with both hijack variants reproduced and repaired on Windows 11 25H2 and Windows 10 22H2. Two corrections to the 2016 version, stated plainly: run.vbs was never a Windows file that a virus deletes — it was the malware itself, removed by your antivirus; and fixing only Userinit, as we originally advised, does not repair the black-screen variant caused by a hijacked Shell value. Both fixes are covered above.