none
BAT files broken after recent Microsoft Update

    Question

  • Been beating my head against a wall. I updated several Windows Server 2003 R2 servers with critical and security updates. On two of them, I've encountered an issue where batch files will not execute if double clicked or called from a run prompt. When they are double clicked I get the error message:

    "The filename, directory name, or volume label syntax is incorrect."

    This is happening with batch files only, so I don't believe its an issue with a folder or drive. Even creating a brand new batch file doing a basic task fails. However, if I open a command prompt and execute it from there it runs fine so I don't think there is an issue with the underlying system, its just something with the Windows Explorer seems broken. I've tried deleting/recreating the file associations under HKEY_CLASSES_ROOT for both .BAT and batfile.

    Really stumped here, hoping someone has seen this or has some idea of what I can do to fix it.


    • Edited by DonNels Friday, June 20, 2014 9:35 PM
    Friday, June 20, 2014 9:33 PM

Answers

  • I've searched all of the common solutions for this type of error, but none of them were applicable. I'm able to open and edit the files just fine, and there is nothing special about the command lines using special characters. These batch scripts all worked fine before, and work fine on most other machines. Even a basic batch script saying "Echo TEST" would not function on the affected machines.

    We ran Procmon on two machines, one working and one not. On the machines where it was working we noticed two successful calls from windows explorer to try and open the file, then a PROCESS create from windows explorer where it hands off to CMD.exe. However, on the machines where it isn't working we see two successful calls then it simply quits. Something is broken with the implicit handoff from Explorer.exe to CMD.exe

    This did not help us determine the root cause of our issue, however it did help us to create a workaround. It seems the implicit call to CMD.exe is broken, so instead we made in an explicit call.

    On a normal machine, HKCR\batfile\shell\open\command is as follows: "%1" %*

    This was how it was on our problem machines as well but it simply wasn't working. So instead, we changed the value of this key to c:\windows\system32\cmd.exe cmd /c "%1" %* <- From our testing with Procmon, we know that this is the call that a normally functioning windows machine knows to make implicitly for .BAT files, but our problem machines do not. After making the a fore mentioned change everything functioned normally with batch files.

    We still don't know what caused it. As others have noted, its clearly not a problem that affects all patched machines, as indeed we had several that continued to function normally despite having received the same patches. The only commonality we could observe is that the two affected machines both started experiencing the issue immediately after they were patched.

    While I'd prefer a better explanation of the cause, I'm happy to have what seems to be a very effective bandaid that didn't involve reloading the OS or anything more extravagant than what we've had to do. Hopefully this helps someone else should they run across a similar issue.

    • Marked as answer by DonNels Wednesday, June 25, 2014 2:26 PM
    Wednesday, June 25, 2014 2:26 PM

All replies

  • I think that's normal if you're trying to execute from UNC path, otherwise these ones might help.

    How to Perform an In-Place Upgrade of Windows Server 2003

    How to integrate Windows Server 2003 Service Pack 2 files into the Windows Server 2003 installation folder

     

     

     


    Regards, Dave Patrick ....
    Microsoft Certified Professional
    Microsoft MVP [Windows]

    Disclaimer: This posting is provided "AS IS" with no warranties or guarantees , and confers no rights.

    Friday, June 20, 2014 10:13 PM
  • These files all worked prior to a recent round of updates. There doesn't appear to be an issue with the files themselves, because I am able to run them just fine from an open CMD prompt. Its when I double click them in Windows Explorer, or try to launch them by going to START -> RUN  that the error occurs. I'm able to right click and edit them, able to double click every other file type. They have no special characters in the file name, nothing exotic is being executed within them that has been traditionally associated with this error.

    I could try to roll back all of the updates I deployed, however even if that fixes the problem without knowing which one caused it I'm leaving myself open to this occurring again in the future,

    Monday, June 23, 2014 2:04 PM
  • I have fully patched servers without this problem. I think problem lies elsewhere. I'd try logging on as another (or new) user to test for profile damage. If it still happens with a new user then I'd try the repair install.

     

     

     


    Regards, Dave Patrick ....
    Microsoft Certified Professional
    Microsoft MVP [Windows]

    Disclaimer: This posting is provided "AS IS" with no warranties or guarantees , and confers no rights.

    Tuesday, June 24, 2014 12:25 AM
  • the batch file does what operation?

    would it be okay to share your batch file, just change parameters that should not be shared.

    or check out this link from Technet about the error.

    http://technet.microsoft.com/library/Cc956689

    ===========================

    from above link:

    Error Message:

    The filename, directory name, or volume label syntax is incorrect.

    Explanation:

    The system does not accept the keyboard combination Alt+0 through Alt+32 or the following characters: \\ \\ / [ ] : | < > + ; = . ? "

    User Action:

    Correct the file name or volume label and try the command again.


    Every second counts..make use of it. Disclaimer: This posting is provided AS IS with no warranties or guarantees and confers no rights.
    IT Stuff Quick Bytes

    Tuesday, June 24, 2014 1:02 AM
  • I've searched all of the common solutions for this type of error, but none of them were applicable. I'm able to open and edit the files just fine, and there is nothing special about the command lines using special characters. These batch scripts all worked fine before, and work fine on most other machines. Even a basic batch script saying "Echo TEST" would not function on the affected machines.

    We ran Procmon on two machines, one working and one not. On the machines where it was working we noticed two successful calls from windows explorer to try and open the file, then a PROCESS create from windows explorer where it hands off to CMD.exe. However, on the machines where it isn't working we see two successful calls then it simply quits. Something is broken with the implicit handoff from Explorer.exe to CMD.exe

    This did not help us determine the root cause of our issue, however it did help us to create a workaround. It seems the implicit call to CMD.exe is broken, so instead we made in an explicit call.

    On a normal machine, HKCR\batfile\shell\open\command is as follows: "%1" %*

    This was how it was on our problem machines as well but it simply wasn't working. So instead, we changed the value of this key to c:\windows\system32\cmd.exe cmd /c "%1" %* <- From our testing with Procmon, we know that this is the call that a normally functioning windows machine knows to make implicitly for .BAT files, but our problem machines do not. After making the a fore mentioned change everything functioned normally with batch files.

    We still don't know what caused it. As others have noted, its clearly not a problem that affects all patched machines, as indeed we had several that continued to function normally despite having received the same patches. The only commonality we could observe is that the two affected machines both started experiencing the issue immediately after they were patched.

    While I'd prefer a better explanation of the cause, I'm happy to have what seems to be a very effective bandaid that didn't involve reloading the OS or anything more extravagant than what we've had to do. Hopefully this helps someone else should they run across a similar issue.

    • Marked as answer by DonNels Wednesday, June 25, 2014 2:26 PM
    Wednesday, June 25, 2014 2:26 PM