VBScript ends after Windows 11 24H2

garlin

Moderator
Staff member
Messages
7,016
Reaction score
3,477

1. W11 24H2 will be the last release that enables VBScript to run by default.
2. Afterwards in 2027, you will have to manually enable it as a Feature on Demand.
3. Disappears completely from Windows in the W12 timeline.

Undoubtedly, some of you depend on the "invisible" VBS trick for hiding running CMD or PS scripts. No word yet if MS will provide an alternative method. The last time I checked PowerShell's open bugs, the PS team was pointing fingers at CMD/Terminal team ("hey, the visible window is a problem with their code").
 
The title is misleading, disabled by default doesn't mean end :D

fyi, wmic.exe isn't disabled by default in 24H2, but LCU (560 or 712) disable it
 
Thanks for the clarification, nuhi shared the same observations on the latest round of 24H2 updates disabling WMIC.
 

1. W11 24H2 will be the last release that enables VBScript to run by default.
2. Afterwards in 2027, you will have to manually enable it as a Feature on Demand.
3. Disappears completely from Windows in the W12 timeline.

Undoubtedly, some of you depend on the "invisible" VBS trick for hiding running CMD or PS scripts. No word yet if MS will provide an alternative method. The last time I checked PowerShell's open bugs, the PS team was pointing fingers at CMD/Terminal team ("hey, the visible window is a problem with their code").
It might be a bit late, but I hope this helps some people. using conhost as "successor" of your VBS hidden scripts trick
I found this post and have been using it both at work and in my personal life. Just be aware of the still unresolved issue regarding the returncodes .
 
I'd like to find out after which version of Windows, did conhost.exe pick up this undocumented feature?

Windows security researchers are all jumping over this trick, for the obvious reasons. The question is at what point does a script containing it get quarantined by an overly aggressive security product?
 
I'd like to find out after which version of Windows, did conhost.exe pick up this undocumented feature?

Windows security researchers are all jumping over this trick, for the obvious reasons. The question is at what point does a script containing it get quarantined by an overly aggressive security product?
Sadly i don't have an exact answer but at least since 2022 (source).
Other more or less unsecure methods, partially with enabled windows scripting host
(Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows Script Host\Settings\ DWORD32 Enabled = 1)
but with (still) supported .js instead of .vbs are descibed here: reddit-post.
Some other methods expect, that you already have an open console window and so on...
 
The MS devs on your linked GitHub issue talk about "--headless" being implemented to support ConPty. Most folks don't realize the Terminal team took over conhost, even though it's a separate Windows feature.

Looking back, there's a 2018 dev blog about upcoming ConPty changes. It's probably safe to extrapolate this feature's been added since W10 20H2, so it covers most of the W10/11 releases people are still running.

Windows Command-Line: Introducing the Windows Pseudo Console (ConPTY)

Yes, it did find AveYo's thread hilarious. I don't know if the MS dev team really know who he is...
 
Back
Top