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

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 NagarajanMicrosoft contingent staff, Moderator Monday, May 25, 2015 6:45 AM
• Unproposed as answer by Alan.M Tuesday, June 02, 2015 8:22 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 NagarajanMicrosoft contingent staff, Moderator Thursday, May 28, 2015 10:13 AM
• Unmarked as answer by Alan.M Tuesday, June 02, 2015 8:22 PM

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 02, 2015 11:26 PM

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

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.

• Edited by Michael CurdMicrosoft employee, Moderator Tuesday, June 09, 2015 6:48 PM

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 09, 2015 8:25 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.

• Marked as answer by Michael CurdMicrosoft employee, Moderator Friday, June 19, 2015 6:10 AM

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.