Webclient crashing issue. Making server unresponsive and require reboot to fix.

Webclient crashing issue.  Making server unresponsive and require reboot to fix.

Quite a few other people seemed to have experienced it too.

https://windoh.wordpress.com/2012/02/04/webclient-service-crashes-on-windows-7-or-windows-server-2008-r2/

https://deangrant.wordpress.com/2013/09/27/web-service-terminates-on-clients-connecting-to-webdav-resources/

https://support.microsoft.com/en-gb/kb/2548470

Above seemed to highlight a fix to the issue that was found out with our Server that had to invoke the WebClient Service when writing files to a WebDav location.

We had a .NET Windows Service Program that would write files in a scheduled manner to a WebDav location.  And what actually caused the server crash was interesting.

The service program ran without problems under a service account.  However, it was when if someone else had logged into the Server with an RDP session and then tried to perform some standard actions with the WebClient i.e by simply navigating to a folder with it, it would cause the Service and WebClient to crash and the server would start becoming unresponsive to a point the only option was to reboot. 

Applying the fix seemed to have made it better.

WebClient Service File Size and File Attribute limits

This keeps on coming back but when opening a SharePoint location with WebDav running the WebClient Service.

There are 2 parameters that we became very aware of recently else files won't open or directories with large amount of files won't show in Windows Explorer view.

The attribute FileAttributesLimitInBytes under HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\WebClient\Parameters.  The controls the limit to the file attributes size that is returned.  It is set to 5 meg by default, I think.The settings are in bytes thats why its so big in size.

5 meg will probably be enough for say 7000-8000 file attributes.

Increase the size if more files are returned by a directory.  Else a timeout like message gets shown by Windows Explorer.

If there are actual files that needs to be read from a SharePoint location that exceeds 50 meg.  The FileSizeLimitInBytes attribute needs to be adjusted under HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\WebClient\Parameters.  It is set to around 50 meg by default.  Set it to higher if required to read larger files.

Restart the WebClient service for it to take effect.

Dangers to AD account's username ID being renamed

This has struck us finally, where some users who have had account IDs changed in the AD starts experiencing problems accessing the site.

For example, I was once mydomain\kong kong  now I have had my ID changed to mydomain\kong lo

You might find the problems of logging into SharePoint site becomes intermittent or seems to work but then suddenly stops working.

You will also find that it is possible that adding the old account ID's access can still work. Although sometimes, SharePoint will prevent you doing it by warning the account is not unique.

It is best for situation like this to do an STSADM -o migrateuser command for these users in order to get rid of the the anomaly with the old account ID lying around in SharePoint's site collection user table.

See post below.

http://littletalk.wordpress.com/2009/12/14/the-user-does-not-exist-or-is-not-unique/

However, the thing to be most careful about is if this has happened to a Service Account that is being used to systematically access SharePoint libraries from say a batch program on a Server.

Granting the access to the old now renamed account ID can have fatal consequences for the WebClient Service that runs.  It can crash it and the only way to recover it is to reboot the server or kill it via the task manager after knowing its process ID.

http://support.microsoft.com/kb/2548470

The crash can happen not immediately after granting the access to the old account ID, it can look like all is fine and even files can get written into SharePoint, until all of a sudden may be a Windows Server Audit process runs, it probably flags up the access violation and crashed the WebClient service causing the problem.

Index Dat file 16 meg Gotcha

We had a batch program that copied files using webDav to SharePoint locations.  Sometimes it would completely die and hay we get to hear all the noise.

It turns out its a feature of the webDav process running with the WebClient Services.  It builds a file called Index.dat in the 
C:\Documents and Settings\LocalService\Local Settings\Temporary Internet Files\Content.IE5 directory

It grows everytime more files are written to location and guess what there is an upper limit of 16 meg for the file.  Therefore, if its over that, the mechanisms crashes and you have to reset the file to get going again.

The following actions need to be performed by a Server Admin. 

1.  Login to the server where the batch program runs from.  Login with the account that the job runs under.  It caches something with the account logged in used to re-start it that suppresses any challenge and response prompt after reactivation.

2.  Open a Cmd Prompt window then run

3.  Run the following command.

net stop webclient 

net stop mrxdav 

4. Then backup the Index.dat file located in C:\Documents and Settings\LocalService\Local Settings\Temporary Internet Files\Content.IE5

5. Then delete the Index.dat file located in C:\Documents and Settings\LocalService\Local Settings\Temporary Internet Files\Content.IE5

6.  Run the following command.
net start mrxdav 

net start webclient 

7. Then quick test, On Run command box navigate to the webDav location eg \\xxx.com\test\Shared

Voila Voila, the noise starts dying.

Updated, seems like Win Server 2008 with IE10 and beyond may not suffer this issue anymore. The file names have changed too and the index.dat file is called WebcacheV01.dat.

C:\user\username\AppData\Local\Microsoft\Windows\WebCache\WebcacheV01.dat

There does not seem to be a file size limit to this either. http://www.sevenforums.com/browsers-mail/311407-ie10-uses-webcachev01-dat-vs-index-dat-files-how-clear-delete.html

Having to Restart WebClient Service from CMD Line for WebDav location in SharePoint to work

This continues to baffle us.  A section of our users require the WebDav protocol to work when browsing to a SharePoint location.

For example on Run \\xyz.com\it\shared documents\

They expect it to open a the location and not prompt for user name and password and when it opens in Window Explorer they should see \\xyz.com\it\shared 

documents\ in the address bar rather than http://xyz.com/it/shared documents/ 

It turns out, users must first have the hostname of xyz.com set into IE's Intranet zone as the browser settings has influence over Windows Explorer when opening WebDav locations.

Then one must have the WebClient Service running in order for it to work properly else it tends to open in http: protocol.

Now here is what got us.  Sometimes even if WebDave service reports running.  It is necessary for some strange reason to restart it.

It is mainly either because the service has :

-Cached something based on the local admin's credentials therefore causing a prompt to appear.
-It has actually somehow not started properly because the service has a dependency on the MRXDAV services.

Therefore, what we must do is simply in the command line and run these 4 commands in the order below.  Has to be done on command line.

NET STOP WEBCLIENT 
NET STOP MRXDAV 
NET START WEBCLIENT 
NET START MRXDAV


Then try opening a location in the Run again and it should start to work.

This KONGED us for a while.

On a Win 7, Vista machine it seemed like the order for restarting the webclient has changed.

NET STOP MRXDAV  - This will then prompt WebClient to be stopped.  Click Y
NET START MRXDAV
NET START WEBCLIENT

Also, when we try to locate a WebDAV location that is in SharePoint, the prompt will continue to appear even if it is inserted into Intranet zone.  We found that we must have this registry key set and then restart WebClient for the authentication pass through to work.

See here

http://support.microsoft.com/kb/941050/en-us

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WebClient\Parameters\AuthForwardServerList