Windows 10 1803: cannot open Mailslot using computer name or IP address. Fails Error 53 ERROR_BAD_NETPATH RRS feed

  • Question

  • After installing build 1803 on multiple computers, software that use mailslots to communicate between computers can no longer send messages.  Specifically, attempts to open a mailslot when using a computer name or IP address will fail.

    So for example, consider this WIN32 API call:

    LPCTSTR lpszSlot = "(see test cases below)";

    Here's the results for the following test cases:

    \\.\mailslot\testSlot // This will still work in build 1803 \\anyComputerName\mailslot\testSlot // Fails with Error=53 ERROR_BAD_NETPATH \\localComputerName\mailslot\testSlot // even on same computer Fails with Error=53 \\\mailslot\testSlot // Any IP address Fails with Error=53 \\\mailslot\testSlot // localhost address. Fails with Error=53

    \\*\mailslot\testSlot // interestingly, broacasts still work in 1803

    On Windows 10 build 1803, software that worked previously for many years will fail on the call to CreateFile in all cases except for a locally referenced mailslot using \\.\  Referencing a local mailslot using the local computer name or IP address will fail.  In build 1803, the same error results regardless of whether the computer name is valid/invalid and regardless of whether the actual mailslot is currently created.  Under previous versions and builds of Windows, the CreateFile would always succeed even if the computer or mailslot did not exist; however, subsequent calls to WriteFile may fail if the mailslot did not exist.

    Note that this failure occurs when opening a mailslot to write into.  Mailslots may still be created, and can be written to from either the same computer (with build 1803 or 1709) or remote computers (only if the remote computer has build 1709 or earlier).  That is, a computer running Windows 10 build 1803 may still create a mailslot and receive messages from computers running older builds of Windows, but a computer running 1803 cannot open a mailslot to another computer.

    This problem occurs on Windows 10 Home and Windows 10 Pro.  Also, it fails even if any firewall software is disabled, so it does not seem to be a blocked port.  I have compared services, NetBIOS, and SMB settings on computers that work and don't work, but have not yet found any differences.

    I suspect that the ability to send outbound mailslot messages has been removed or at least disabled in build 1803 for security reasons.  It also may be totally accidental, since inbound mailslot messages can still be received.

    Is this a bug? a feature removal? or is there some way to re-enable mailslots?

    For details and sample code see also this entry on stack overflow.

    • Edited by some_coder Friday, May 25, 2018 8:05 PM edited to note broadcasts still work
    Thursday, May 17, 2018 3:35 PM

All replies

  • We are also affected by this issue. We are telling Windows 10 users to rollback to 1709. We need a statement from Microsoft ! 

    Thursday, May 17, 2018 8:22 PM
  • Hi,

    Considering the Update is released recently, if the issue persists, you could try the built-in "Feedback" tool to submit the issue on your side.

    Best Regards,


    Please remember to mark the replies as answers if they help. If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.

    • Proposed as answer by Tony_Tao Thursday, May 24, 2018 7:45 AM
    Friday, May 18, 2018 4:30 AM
  • I posted a built-in feedback first, but not sure if that's effective for something obscure like this.  I was hoping someone here would know a better way to diagnose or re-enable mailslots.  
    Friday, May 18, 2018 2:58 PM
  • It seems to be a bug where CreateFile is incorrectly rejecting \\computerName\mailslot\slotName as an invalid network path.  If it were a security tightening or intentional feature removal, it seems odd that both receiving mailslot messages and sending broadcast mailslot messages to all other computers in the workgroup/domain still work.
    Friday, May 25, 2018 8:09 PM
  • I'm dead in the water with this bug, as well.  I'm unable to debug any U-SQL scripts with code behind or other c# projects since the update.  I've been thinking this was a VS 2017 update I got, but I did also receive a Windows Update around the same day, as well.  I wound up opening a Support Incident late last week, but no updates yet.

    Here's my post regarding U-SQL if anyone else is having that same issue:


    Bill Blakey

    Monday, June 4, 2018 3:26 PM
  • Yep, same bug, Pure windows error. This is affecting more than 10k our customers. Please fix immediately.

    Mailslots are used as non-reliable communication and failure does not prevent usage but will cripple part of funtionality.

    We can not control what version of windows clients are using, it is up to their IT organisation to decide.

    Even some workaround would be nice to have, changing my code is easy and giving it to affected customers is doable ( pain in the ass and will cost some money).

    • Edited by Ismo.Salonen Friday, June 15, 2018 4:31 AM Clarification added.
    Friday, June 15, 2018 4:28 AM
  • There are some hacky workarounds since you can leverage the fact that local mailslots work and that broadcasts still work.  Assuming you have a centralized send function, you can route your messages to other specific computers using a socket, pipe, http, or other means. On the receiving computer, you could reduce code changes, by taking the incoming message and posting it to a local mailslot "\\.\mailslot\slotname".  That's very hacky but minimizes the amount of code that would be affected.  Broadcast messages can still be sent on mailslots even in 1803.  

    MS is supposed to be working on this as they noted in another similar bug report. However, we had to roll out a hacky workaround as we could not leave our software non-functional while we waited now almost 2 months.
    Wednesday, June 27, 2018 10:41 PM
  • > Have you tried \\yourComputerIPaddress\mailslot\

    Yes. It fails even if you use an ip address or a computer name even if you use or the local computer name.  The only forms that work are \\.\mailslot\slotName or \\*\mailslot\slotName.  To me, it seems to be a problem in the validation of the pathname within CreateFile which rejects the pathname. It fails pretty much immediately regardless of whether a valid or invalid ip address or computer name is used, so it seems to reject the syntax of the request without even trying to use the address.

    • Edited by some_coder Friday, July 6, 2018 2:33 PM
    Friday, July 6, 2018 2:29 PM
  • Keeping the thread alive.

    Any word from Microsoft Windows 10 update support?



    Wednesday, July 11, 2018 4:48 PM
  • I doubt that the request reaches the router, because I can try various valid and invalid ip-addresses or computer names and they all get rejected immediately.  It seems that simply the form \\X\mailslot\slotname gets rejected as ERROR_BAD_NETPATH except for X==. or X==*

    Thursday, July 12, 2018 9:42 PM
  • This is the only Microsoft reply that I can find related to this bug.  The MS tech indicates a fix was released, but the MSDN team just worked around the problem as I had to do rather than wait for the Windows team to fix the issue.  The same tech had previously stated the Windows team were treating it as a priority fix.  
    • Edited by some_coder Thursday, July 12, 2018 10:05 PM
    Thursday, July 12, 2018 9:52 PM
  • After "2018-09 Cumulative update for Windows 10 version 1803" installation the mailslots work OK.
    Thursday, October 11, 2018 10:16 AM
  • I'm not able to get either the 2018-09 or 2018-10 cumulative updates to install currently. I'm not sure if that's because MS pulled them back or my computers already have some of the updates.

    @Milan Zeman: Do you know for sure that your computer with 1803 was failing with mailslots (before the 2018-09 update) ? And do you happen to know what Windows version number and OS build number your computer showed before and after that update?

    Wednesday, October 17, 2018 8:39 PM