Downloaded toolkits contain everyone else's habits. Your batch files contain yours — the checks you always run, in your order, with your safety pauses. This is how to build a Scripts folder that survives any drive letter and never surprises you.
The most personal part of Technical Anshu's custom build is the part no download can give you: his own scripts, shaped by thousands of CMD commands and real repairs. A batch file that runs your standard diagnosis, your disk check, your data-rescue copy — in one click, identically every time — is worth more than another hundred downloaded tools. This guide covers writing them safely: finding the right drive, refusing to guess, and logging what happened.
In WinPE, drive letters move. The patient's Windows might be C:, D: or E: depending on the machine, and a script that assumes C: will happily repair the wrong partition — or your own toolkit stick. Every repair script starts by detecting the real Windows drive: loop through letters and test for \Windows\System32\ntoskrnl.exe, store the winner in a variable, and stop with a clear message if none is found.
The pattern looks like this in a batch file: for %%D in (C D E F G) do if exist %%D:\Windows\System32\ntoskrnl.exe set WIN=%%D: — then every later command uses %WIN%. Five seconds of detection removes the single most dangerous assumption in offline repair scripting.
A small launcher keeps scripts usable under pressure. The choice command waits for one keypress: choice /c 12340 /n sets errorlevel to the position of the key, and if errorlevel lines route to each script. Check from the highest number downwards — errorlevel tests mean 'this value or higher', the classic batch trap.
Keep the menu short: disk check, offline SFC and DISM, data rescue, boot repair, exit. Each entry calls a separate small script rather than one giant file, so one broken script never takes the whole menu down, and updating a single routine never risks the others.
Scripts get launched from Explorer, from a command prompt, from another script — and the 'current folder' is different each time, so relative paths break exactly when you rely on them. Batch files solve this with %~dp0, which expands to the script's own folder wherever the stick is mounted: start %~dp0..\Tools\Disk\DiskHealth.exe reaches a tool relative to the script, on any drive letter, on any machine.
Apply the same thinking inside the scripts: log files written to %~dp0Logs, rescue copies aimed at a drive the script asks you to confirm — never a letter guessed at the top and forgotten.
A repair script must be boring in the right places. Before any destructive step — a disk fix, a boot rewrite — print what is about to happen and wait: pause costs two seconds and has saved more data than any tool on the stick. Read-only checks (disk health, file scan without fixing) can run unattended; anything that writes gets a confirmation.
End every script by appending one line to a log on the stick: date, machine, what ran, what it reported. Six months later that log is your evidence of what was done to a customer's PC, and your best teacher about which repairs actually recur. Scripts that log themselves turn one technician's experience into a system.
The video's toolkit is built around this one-click idea — watch it, then start your own Scripts folder with one routine.
▶️ Watch Full VideoYes — WinPE runs a startup file (winpeshl.ini or startnet.cmd depending on how the image was built), where you can launch your menu script. Keep the auto-start minimal: network init and your menu. If the menu script ever breaks, a heavy auto-start chain can leave you with a PE that boots to nothing useful.
Batch runs everywhere in WinPE with zero setup, which is why it suits the boot environment. PowerShell is stronger for structured data and logging but needs the PowerShell component added to the WinPE image. Many builders use batch for the boot-time routines and keep PowerShell scripts for work inside a running Windows.
End interactive scripts with a pause, and launch them from a menu script that returns to the menu afterwards. For diagnosis scripts, also write the key results to the log file — the screen is for the moment, the log is for the record.