Sometimes I Can Access the WebDAV Share, Sometimes I Can't!

You probably already know that all of the Sysinternals tools, such as Process Monitor, Process Explorer, Autoruns, and much more, can be accessed via "shared folder" from any computer connected to the internet by navigating to \\\.  This isn't the same kind of share you'd create if you just shared a folder on your PC.  It's a WebDAV share, and is accessed over HTTP.

Sometimes though, I feel the need to access this share from the command line, either in the Cmd shell or Powershell.  Alas, here's what I see:

Network path not found*Path not found.*

I get the same result with Powershell. Bummer. Well I know I can access the path with Explorer when I type that same UNC into the address bar, or if I just type the UNC into the Run dialog box, so this must just be a limitation of those command-line tools, right?

It works in Explorer*Works fine in Explorer*

Oh well... but wait. Now having successfully accessed the network path with Explorer, let me now immediately go back to the Cmd shell and try it again:


Now it works in Cmd too!*Now it works in Cmd too!*

OK, now accessing the network path works fine from the Cmd shell and from Powershell, even though all I did was access it through Explorer first, and then try again. Now I just have to know what the heck is going on... and to do that, I need to use Process Monitor. Which, amusingly, is in the WebDAV share I'm trying to access. But I'll run a local copy.

I started the trace. Here's my first attempt to access the network path with Cmd.exe, which failed:

Cmd.exe network path not found*Network path not found*

This was the very first time in the Process Monitor trace when the string "" appeared in the Path field. It's also the first time the Cmd.exe process shows up in the trace. It's currently filtered to only include events where the Path field contains the string The really interesting part about this is that it appears the moment I pressed Enter on the command line, Explorer.exe was the first process to be involved, not the process I was interacting with! That's odd. Maybe a file system filter driver intercepted the call and notified Explorer? It looks like Explorer is looking for something related to named pipes and the Workstation Service (wkssvc) on the remote server, but it doesn't find it.  Then Cmd.exe first checked my local file system for a file in Windows\CSC\ directory, which it didn't find, and then it tried to access the network path that I actually asked for, which resulted in "Bad network path." Then it apparently tries again with the same local file system path, and then again with the network directory instead of the specific executable name.  All failed. "Network path not found," my command prompt tells me. But with no further input from me, Explorer takes off doing its own thing, calling cscapi.dll and loading things in the background and sending things over network. All I did was hit enter in the Command Prompt above.

So what is this CSC directory? Googling the term led me to an old post on Raymond Chen's blog. Client Side Caching. OK, so apparently both processes are looking for a cached or offline version of the network path.

Then I move over to the Explorer.exe window and type the path into the address bar. Explorer looks for some more CSC stuff first, and then svchost.exe starts communicating with the remote server over TCP. There's a lot of loading of WebDAVRedirector stuff. Finally, after a lot of work, I start seeing events like these from Explorer:

Explorer finds it, finally*Explorer starts finding it, finally*

Notice that Explorer also seems to be storing the autoruns executable in a temporary "Tfs_DAV" directory on my workstation.

Finally, after having success with Explorer, I go right back to the Command Prompt and try it again. This time, the trace looks like this:

Works in cmd.exe now too

Now I see svchost.exe stepping in with a WebDavRedirector, and cmd.exe getting some successful returns from its IRPs. Finally, after playing around in that Tfs_DAV directory and some more intermingling of svchost.exe and the System process both helping out, the process autoruns.exe finally launches.

So that's a pretty fast and loose overview of what is actually going on. The entire trace was a beast to wade through, and there is obviously a lot of orchestration and cooperation required between many different Windows components required to allow you to access a WebDAV share from within Cmd.exe and I don't fully understand all of it... but the bottom line is that at least on my Windows 7 SP1 x64 workstation, it looks like Explorer.exe is smart enough to read from a WebDAV share and cache the data locally, whereas Cmd.exe is only smart enough to read the data locally, if and only if it's already cached locally... or perhaps the redirector had to be "woken up" by Explorer first, before Cmd.exe was able to use it.

Finally, I'll leave off with a bit about the WebDAV Mini-Redirector from Wikipedia:

"In Windows XP, Microsoft added the Web Client service is also known as the WebDAV mini-redirector[11] which is preferred by default over the old Web folders client. This newer client works as a system service at the network-redirector level (immediately above the file-system), allowing WebDAV shares to be assigned to a drive letter and used by any software. The redirector also allows WebDAV shares to be addressed via UNC paths (e.g. http://host/path/ is converted to\\host\path\) for compatibility with Windows filesystem APIs."

Comments (4) -

Christian Turri 12/7/2012 7:20:55 AM

Great post Ryan, which I found when Googling for the "BAD NETWORK PATH" event within a WebDAV read. Still you are missing the solution to this problem, which I am also trying to find. Unknown to many every Sharepoint document library is exposed to the world via WevDAV. We use this feature to read Excel files stored in Sharepoint in IIS which runs our reporting application. So far I have experimented with different solutions to this problem, the main one being by using a third party tool that creates a custom Windows service that runs a WebDAV UNC path at boot time. It's worth noting that the account we use to do that is different than the one we use to run IIS. It's also worth noting that the UNC path we use to "initialise" WebDAV does not have to be the one our application will use, in other words once we "seed" a WebDAV UNC path then all subsequent reads will work fine, regardless of the UNC path or Sharepoint server we want to reach. Still it will be better to find out exactly how to do this properly rather than having to "hack" solutions...

Christian Turri 12/7/2012 7:46:42 AM

It looks like I was digging too deep into this problem when I knew the solution from the start. However your article refreshed me something I already knew, the WebDAV redirector runs as part of the Web Client service. While this is included by default on Windows XP, Vista, & and Server 2003, it is not included on Windows 2008 Server. This can be installed via the Desktop Experience server feature. Anyway the solution is very simple, just set the Server to Automatic and restart your PC/Server. Once that's done WebDAV resources will work fine without having to use Windows Explorer first. In fact you can verify this but you will see that when you run WebDAV resource on Windows Explorer the Web Client service is started, if it wasn't started already. That is the reason that all it takes to be able to read WebDAV resorces is to hit Windows Explorer once for it to work fine after that. Thanks for the good post anyway!

Awesome - thank you for these very helpful comments.  Indeed the WebClient service on my Windows 7 laptop is set to Manual and is currently stopped... which perfectly explains this behavior.


Thank you very much for the article and the subsequent comments that pointed me in the right direction.

I arrived at the same conclusion by using process-monitor although different results. Its the webclient-bit which i couldnt deduce. I arrived at webclient service but missed the "automatic" start option. When i looked at it, it was already running so didnt pursue that any further.

I have a sharepoint 2010 server with desktopexperiecnce installed.
Also have an excel spreadsheet pulling data into powerpivot from another xls in a different document library.

The setup would work with manual refreshes, but a scheduled data refresh would always fail with the following error -

OLE DB or ODBC error: Failure creating file.; 3436. A connection could not be made to the data source with the DataSourceID of '123a7c81-89af-42e8-9d9f-461e168a1400', Name of 'Excel timings'. An error occurred while processing the 'Installations' table. The operation has been cancelled.

It will work once i login to the server and access the source spreadsheet in sharepoint using a UNC address.
It took me a while to deduce the workflow.

Thanks again to your article and the useful comments.


Comments are closed