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

    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)";
    HANDLE hSlot = CreateFile(lpszSlot, GENERIC_WRITE,FILE_SHARE_READ,(LPSECURITY_ATTRIBUTES)0,OPEN_EXISTING,FILE_ATTRIBUTE_NORMAL,NULL);

    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 \\192.168.10.1\mailslot\testSlot // Any IP address Fails with Error=53 \\127.0.0.1\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,

    Tao


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

    Friday, May 18, 2018 4:30 AM
    Moderator
  • 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:

    https://social.msdn.microsoft.com/Forums/azure/en-US/be9daba1-edb2-4c6d-bdea-f98c47675226/cannot-debug-local-c-code-used-in-usql-script-since-vs2017-1571-upgrade-yesterday?forum=AzureDataLake&prof=required


    Bill Blakey

    Monday, June 04, 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