220-1102 Software Troubleshooting Practice Question

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✗

  End the wscript.exe process and delete the script.vbs file.

  Why it's wrong here

  Terminating the wscript.exe process and deleting the script.vbs file only removes the currently visible symptom. The malware almost certainly established persistence through an HKCU\...\Run registry value, a Scheduled Task, or a WMI event subscription, so it will relaunch after the next reboot or user logon. Additionally, the script may be locked by the running process or protected by file permissions, making manual deletion unreliable. The correct approach is to isolate and clean the infection with antivirus software that can neutralize both the file and its persistence mechanisms.

• ✗

  Run System File Checker (sfc /scannow) to repair system files.

  Why it's wrong here

  System File Checker verifies and repairs only protected Windows system files by comparing them against the component store. A VBS script dropped by malware is not a protected system file, so sfc /scannow will neither detect nor delete it, nor will it remove registry entries or scheduled tasks that execute the script. This command is useful for repairing corrupted Windows binaries, but it is not a malware removal tool and provides no benefit against script-based infections like this one.

• ✓

  Reboot the system into Safe Mode and perform a full antivirus scan.

  Why this is correct

  Safe Mode loads a minimal set of drivers and services, which prevents the VBS script's usual startup methods—such as Run registry keys and startup folders—from executing automatically. This gives antivirus software a clean environment where the malware cannot actively hide, respawn, or interfere with scanning. After booting into Safe Mode with Networking (if needed for updated definitions), run a full system scan to detect, quarantine, and remove the script and any persistence artifacts it created. This is the standard first step for cleaning an active script-based infection.

• ✗

  Disable the wscript.exe process from starting automatically using msconfig.

  Why it's wrong here

  Using msconfig to disable the wscript.exe entry in startup does not affect the instance of wscript.exe that is already running in memory, so the malware remains active in the current session. Disabling startup items only prevents automatic launch on the next boot; it does not delete the script.vbs file, remove its scheduled tasks, or clean its registry persistence. Furthermore, wscript.exe is a legitimate Windows component, so globally disabling it could break other administrative scripts, while the malicious script could still be triggered by other means. A targeted cleanup with antivirus or manual removal of the persistence points is required.

Go deeper

Related to this question