Solved Did 24H2 break the waitfor command?

In an unelevated command prompt:



In an elevated command prompt:



This worked fine before the update.

I see I'm not getting any help here. I'm not expecting any quick bug fix from Microsoft either. So I've come up with an alternative way of accomplishing what I want. I'm including 3 .bat scripts that demonstrate my approach. Since this site doesn't permit .bat files as attachments, I've included them inline in this post.

Main.Bat:

:Again

In here I have
various commands that
do some processing that
I want to happen every
6 hours.

rem This places a time stamp in the command window.
Time /t

Call WaitForTimerExpired

GoTo Again

---------------------------------------------------------------------------

WaitForTimerExpired:

echo off
rem Since this script is invoked via Call from Main.Bat, it runs in the same command window.
rem I want it to be silent, hence the echo off.

rem I use the TimeOut command to delay for 6 hours. TimeOut is a delicate command. If a TimeOut is running in a
rem command window & you happen to bring that window into foreground, any keystroke immediately expires the TimeOut.
rem Even Alt+Tab to switch away from the window where the TimeOut is counting down causes the interval to immediately
rem expire. Yes, I know about the /nobreak parameter. You'll see below that I do use it. But I like the idea of being able to
rem trigger my Main.Bat process on demand, before a 6-hour interval might have elapsed. That would be in addition to the
rem possibility of just letting it wait the full 6 hours. In order to let me easily inspect my Main.Bat window without worrying
rem about accidentally expiring the interval, I have isolated the 6-hour TimeOut command in a separate task. That's why
rem I have this perhaps slightly elaborate setup.

rem Launch the timer in a separate task.
Start " " /Min Timer

:PollAgain
rem Even though I have echo off at the top of this script, the TimeOut command insists on displaying its countdown
rem message, even when I had @ at the beginning of the command. I don't want to see that message. So I redirect
rem the countdown message to a file, which I immediately delete.
TimeOut /t 60 /nobreak 1>Junk
erase Junk

If Not Exist Semaphore.Txt (
GoTo PollAgain
) Else (
Erase Semaphore.Txt
)

GoTo SkipComment

This script is invoked by a Call from the Main.Bat script. That means I can't code an Exit in this script. An Exit in this script would terminate Main.Bat as well. When execution gets into the Else above, flow of control falls down to here. The end of the file implicitly returns to Main.Bat. There is no Return command in this language. How silly. Whatever. Deal with it.

The idea here is that at a rhythm of once per minute I check for the existence of the semaphore file. As long as it doesn't exist, the timer is still in the process of counting down. Once the semaphore comes into existence, that's my signal that the timer has expired. And by the way, Timer.Bat has ended. The contents of the file are of no use or interest. I just delete the file & return to the main program, which then loops back around & does its processing again. It then issues another Call for this script.

I wasn't entirely sure to what extent the echo off in this script would affect the calling script. Experimentation shows that echo off persists after this script returns. I don't want that. So I reinstate echo before I go back.

:SkipComment

echo on

---------------------------------------------------------------------------

Timer.Bat:

rem This is the slave timer task for Main.Bat. This isolates the TimeOut command in its own window, thus making it easy to avoid
rem accidentally triggering the premature completion of the wait interval. TimeOut responds to just scrolling its command window
rem & even Alt+Tab. Completing the interval makes the primary process repeat. I don't always want that. So I've isolated the
rem overly sensitive TimeOut command here so the main process can remain in its own command window where I can see when
rem it last ran without accidentally making it run again. But I still have the option of triggering the main task by jostling this window.
Time /t
TimeOut /t 21600

rem This is where I used to issue a Waitfor /si command. I no longer care whether that ever gets fixed. This is the
rem approach I will be using indefinitely.

rem This creates a file that contains the text "Expired" as its only line. The text is of no importance.
rem Only the existence of the file is of any importance.
Type Expired 1>Semaphore.Txt

Exit

---------------------------------------------------------------------------

I really wanted to let the Task Scheduler take care of this. At the time I originally wrote this collection of scripts, I believed it wasn't possible to use the Task Scheduler to schedule a recurring process on a timer whose duration was of my choosing. But I've looked at it again more closely & I believe I actually could do this through the Task Scheduler. But at this point, it's not worth the bother. What I'm showing above does what I want. It works. I'm not fixing it. If I ever have a need some time in the future for a process that runs on a timer, I'll define it in the Task Scheduler.

Short answer: Yes.

waitfor stopped working in 24H2, because the underlying Remote Mailslot IPC protocol was disabled. It's an insecure protocol sitting on top of SMB1 (yikes!).

What's new in Windows 11, version 24H2 for IT pros

Remote Mailslot protocol disabled by default​

Remote Mailslot protocol was deprecated in November 2023 and is now disabled by default starting in Windows 11, version 24H2. For more information on Remote Mailslots, see About Mailslots.

Click to expand...

You can re-enable the protocol from PowerShell:
The beginning of the end of Remote Mailslots as part of Windows Insider

Thanks for the explanation, @garlin. I read the article about mailslots & I have to say that if you hadn't told me this had anything to do with Waitfor /si, I would have had no idea the topics were related. The technique I came up with is, I believe, the long-term replacement for Waitfor /si. I used that command in only one place ever so it's not like I have to scurry around my system looking for all the scripts I have to fix. The solution I outlined above is something I have used before, so I guess it's the way to do things now.

Just out of idle curiosity, I'd like to understand the PowerShell solution you offered. Does that PowerShell command durably re-enable Waitfor /si? Is it a one-time fix that enables the signal function after the script in question ends, and across reboots? Or is it something that holds true only as long as the script in question is running, & only in that one script? Do you have to execute the PowerShell command in an elevated command prompt, as you show, or can it also be issued in an non-elevated command prompt? Is that PowerShell command also deprecated? I'm not going to bother with it but the answers might help somebody else coming along after us to read this.

I do have Waitfor /t seconds ThisSignalWillNeverArrive coded in a number of places. I came up with that before I noticed the TimeOut command. It is my way of pausing for a specified time. This is a pause that does not rely on some external event. I don't expect any sort of signal to arrive before the delay interval expires. It's just a wait until a certain time. This continues to work. Is that deprecated as well?

I think it's pretty shady of Microsoft to disable something because of security concerns & not supply a new, secure way of doing the same thing. Interprocess signalling should be built into the operating system. I shouldn't have to turn the somersaults I did to come up with my alternative. I also don't see what the security threat is when I want to pass signals between 2 processes I wrote that run exclusively on my computer, processes that do not communicate across any network to any other computer.

I honestly didn't know waitfor was based on Mailslots, but one of the Google hits on waitfor errors mentioned Mailslots & SMB1. W11 has been steadily deprecating the old SMB1 features for security reasons.

No, the PS command permanently updates the SMB settings on this PC. Since it's already deprecated, it's highly unlikely that a future Windows Update will clobber it. The command must be executed from an Admin shell, since you're changing system-level settings. It probably tweaks some reg keys, and restarts the SMB services.

Technically, waitfor itself isn't deprecated... it just can't run without Mailslots. So I would think waitfor hasn't changed any other traits.

Having worked for a large software company with retired products, I can appreciate how this fell between the cracks. When waitfor was created, Mailslots was probably the best option at the time. But as time moved on, less users depended on both waitfor & Mailslots as newer API's were created. SMB1 is now considered terrible for security reasons, and should be avoided at all costs unless you're locked into supporting legacy systems or devices that only speak SMB1.

There are a number of alternative IPC methods, like named pipes. But waitfor is probably orphaned and hasn't been touched in years. Mailslots itself isn't a security problem, it's the fact the queue was designed to sit on top of SMB1 which causes heartburn. Because to re-enable Mailslots, you've now re-opened the SMB1 security holes which are closed by default. C'est la vie.

Thanks. I guess as long as I use Waitfor but not Waitfor /si, I'll be good. If that stops working, I guess I'll have to come up with some other evasive maneuver . . . like I did when I discovered Waitfor /si was no longer working.

As for named pipes, I looked that up once & I got the impression that it's something you can access in C++ but not in simple .bat files. I also got the impression that named pipes is essentially the mechanism I'm describing above with my 3 scripts, where I create a semaphore file in one task & test its existence in the other task. Right? Wrong?

Instead of redirecting output to a file which you later delete, why don't you redirect to 'null'?

As in Dir>null

Why? Because I'm slow, and contrary to popular belief, I don't know everything.

By the way it's not Dir>null. It's 1>nul. But I do thank you for the inspiration.

WildWilly said:

Why? Because I'm slow, and contrary to popular belief, I don't know everything.

By the way it's not Dir>null. It's 1>nul. But I do thank you for the inspiration.

Click to expand...

dir>null was just an example! 1>null is not a valid command.

Oooohhhhh . . . I see what you mean. I told you I'm slow.

As of now, I'm running like this:

TimeOut /t 60 /nobreak 1>nul

Are you saying I could code it like this?

TimeOut /t 60 /nobreak >nul

Or would it have to be like this?

TimeOut /t 60 /nobreak>nul

That's without the space before the >.

Never mind. I tried it with & without the space before >. It works both ways.

Thanks again.

It does not seem to matter if you have spaces anywhere in ' dir > null'

Got it. I think I'm remembering that if you're coding 1> or 2> or something like that, you can't have a space between the number & the >. A space would set off the number so that the command interpreter would think the number is a parameter for the command. But if you don't have the number, there's no such possibility for confusion.

In my third .bat file above I have a Type command. That's wrong. The script actually works anyway because the redirection on the command creates the file. But contrary to what I said above, it doesn't contain anything. The error message generated by the Type goes to the bit bucket because the .bat file ends right after the error & it is unseen. The correct command is, of course, Echo.

I would have corrected my post above but I don't have the option of editing it. I could have sworn this forum used to let you edit your own posts. Oh well. This will have to do.

Now there's an Edit button on this post. I'm using it to type this. I guess once a certain amount of time has passed, the Edit button disappears. Interesting . . .