none
Does Azure Files have a timeout on established connections?

    Question

  • I have an application deployed in a cloud service, running on multiple Windows Server 2012 R2 virtual machine instances, that uses the Azure Files feature. The Azure Files share is mapped using the net use command, as described in http://blogs.msdn.com/b/windowsazurestorage/archive/2014/05/12/introducing-microsoft-azure-file-service.aspx.

    • e.g. net use z: \\<account name>.file.core.windows.net\<share name> /u:<account name> <account key>

    After almost exactly 1 week (1 week, 8 hours later), .NET code that loads files in the share stopped being able to load files, on both virtual machines.

    The exception that was occurring was (relevant portion of stack trace shown only):

    An unexpected network error occurred. 
    System.IO.IOException
       at System.IO.__Error.WinIOError(Int32 errorCode, String maybeFullPath)
       at System.IO.FileStream.ReadCore(Byte[] buffer, Int32 offset, Int32 count)
       at System.IO.FileStream.Read(Byte[] array, Int32 offset, Int32 count)

    Even though the share was still mapped to the drive, I had to remap the share for the application to start accessing the files again. The error was not short lived either, and was occurring repeatedly for 2 days.

    Are there any timeouts on already mapped shares that would explain this? Or are there any other explanations for why a previously mapped share would stop working?







    • Edited by Alan.M Thursday, May 21, 2015 12:08 AM
    Wednesday, May 20, 2015 11:55 PM

Answers

All replies

  • Hi,

    please check for the orphaned network adapters in the VM and remove them manually. After that reboot the VM once. Check if the issue persists even after that.

    To find the network adapters, open up Device Manager, selected View > Show hidden devices and then expanded Network adapters.

    Regards,
    Manu

    • Proposed as answer by Nagamalar Nagarajan Monday, May 25, 2015 6:45 AM
    • Unproposed as answer by Alan.M Tuesday, June 2, 2015 8:22 PM
    Thursday, May 21, 2015 4:24 PM
    Moderator
  • I am unable to confirm this yet because the problem has not resurfaced, I do have a couple questions though:

    • What does an orphaned network adapter look like?
    • Which hidden network adapters correspond to mapped network shares?
    • What would cause such an orphaned network adapter to get orphaned? e.g. is this a bug in Windows Server or Azure Files?
    Monday, May 25, 2015 11:38 PM
  • Hi Alan,

    Orphaned Network Adapters are hidden/ghost network adapters.
    To view them you would have to type "set DEVMGR_SHOW_NONPRESENT_DEVICES =1"in command prompt and run the command.
    Start devmgmt.msc from run.
    In Device Manager, choose "View/Show hidden devices".
    Under Network Adapters, you would see the Orphaned Network Devices.

    One of the reasons for Orphaned Network Adapters could be if a network share or connection is not truncated completely.
    However it wouldn't be possible to isolate the reason for orphaned network adapter or if this is because of Azure files or Windows Server unless the issue recurs and we are able to obtain a Trace or reproduce the issue.

    Regards,
    Malar.

    • Marked as answer by Nagamalar Nagarajan Thursday, May 28, 2015 10:13 AM
    • Unmarked as answer by Alan.M Tuesday, June 2, 2015 8:22 PM
    Thursday, May 28, 2015 10:13 AM
  • This issue is occurring again. I don't see any difference in the hidden network adapters list after running the command set DEVMGR_SHOW_NONPRESENT_DEVICES=1 versus not running the command. This image shows the full list of network adapters after clicking the View>Show Hidden Devices menu option.

    The "Microsoft Hyper-V Network Adapter" is the only one visible when hidden devices are not shown.

    The list of adapters is exactly the same when the issue is not occurring.

    How do I create a trace for this issue?


    • Edited by Alan.M Tuesday, June 2, 2015 11:26 PM
    Tuesday, June 2, 2015 8:30 PM
  • Hi Alan. Could you please provide your account name and timestamp? I can have someone look into this.
    Wednesday, June 3, 2015 8:27 PM
    Moderator
  • Here is the information you've asked for.

    Account: **redacted**

    Times in UTC (I haven't listed all, just some of the most recent):

    6/3/2015 3:12:50 PM
    6/3/2015 2:12:47 PM
    6/3/2015 7:32:29 AM
    6/2/2015 11:56:24 PM
    6/2/2015 11:54:32 PM
    6/2/2015 11:51:09 PM
    6/2/2015 8:23:21 PM


    • Edited by Alan.M Friday, June 19, 2015 6:46 PM
    Friday, June 5, 2015 12:03 AM
  • Thanks! Going to have someone look into this now.

    Friday, June 5, 2015 9:37 PM
    Moderator
  • Hi Alan. We have identified and resolved this instance of the problem - please confirm you have no further issues. We are also working on a longer term fix for this issue to reduce the likelihood of future occurrences which will be included in an upcoming Files upgrade.
    Tuesday, June 9, 2015 6:46 PM
    Moderator
  • I have VMs I put in the staging slot when this problem last occurred, and they are still having the problem. Are the changes supposed to fix VMs already in this problem state, or does the fix only handle VMs that map shares after the fix was put in place?
    • Edited by Alan.M Tuesday, June 9, 2015 8:25 PM
    Tuesday, June 9, 2015 8:25 PM
  • The problem is still occurring, do I have to wait for the longer term fix before I will see any resolution to this error?
    Tuesday, June 16, 2015 3:35 PM
  • Sorry for the delay Alan. I've been told that you will need to remap those shares on your VMs in order for everything to work again.
    Tuesday, June 16, 2015 11:22 PM
    Moderator
  • Let me know if you're still having problems Alan. If so, I will unmark my answer. Thanks.
    Friday, June 19, 2015 6:10 AM
    Moderator
  • This did occur after remapping. I have resorted to running a scheduled task every 15 minutes that remaps the share and the issue is no longer occurring.
    Friday, June 19, 2015 6:44 PM