This issue has been driving me crazy for a few days now:


When dragging a file (Word Document, PDF, Image, etc.) to a SharePoint 2013 document library to upload said file, it appears to upload the file but then freezes at the below image enter image description here

Though it appears to not work if you simple hit "Cancel" or refresh the page the file shows in the library. So it's working, but there is never any indication to the end user the file has been successfully uploaded.

Another thing that is really throwing me is that this issue is not farm wide (or even web application wide for that matter). I can go to another library in another site collection (same web app and content DB) and it works just fine

Tests / Things I have checked

  • Views - I have tried adding another view but same results
  • Permissions - I have checked all the permissions and see nothing out of place. Have given the test account full control over the site collection and, via inheritance, the library. None of the libraries have custom permissions. Besides I would think if it was a permission's issue the upload would fail.
  • Settings - I have compared settings between working and "problematic" libraries to verify the same settings.
  • Verified there are not custom web parts applied to the library
  • Tried the operation in Chrome, IE11, and Firefox all with the same results. Even tried IE's emulation mode (in 8, 9, and 10) all with no luck.

Logs The ULS logs oddly log the following error:

System.IO.FileNotFoundException: The system cannot find the file specified. (Exception from HRESULT: 0x80070002), StackTrace: at Microsoft.SharePoint.SPWeb.GetFileOrFolderProperties(String strUrl, ListDocsFlags listDocsFlags, Boolean throwException, SPBasePermissions& permMask) at Microsoft.SharePoint.SPFile.PropertiesCore(Boolean throwException) at Microsoft.SharePoint.SPFile.get_CheckInComment()...


  • SharePoint Server 2013 (On-Premise)
  • Configuration database version: 15.0.4797.1000
  • I fear that there is some crucial info missing here, so I can't figure a real answer. But the error message got me wondering... I don't know if that could actually interfere with the upload page but... have you checked if the document library doesn't have any attached workflow/event receiver?
    – SPArcheon
    May 31, 2016 at 18:14
  • @SPArchaeologist So I finally got to test this and found that there were workflows attached to the libraries that were experiencing the issue. Deeper investigation through the ULS logs and event viewer point me to a issue with the database which didn't allow the workflows to run when a item was created/uploaded. Corrected that issue and the libraries started working again. If you make your comment a answer I'll mark it. Thanks!
    – Tom
    Jun 27, 2016 at 16:22
  • Done - it is not much, but it should do. Glad you where able to find out the problem!
    – SPArcheon
    Jun 30, 2016 at 13:06

2 Answers 2


The error message you found in the ULS seems to indicate that a "unidentified" process is having some issues accessing the file.
You already excluded some possible issues: permissions, custom pages/views, custom web parts on the page and so on. The settings for the document library seem to be identical to other libraries where the upload show no problems at all, and you also confirmed that the problem is not browser specific.
Also worth mentioning is that even if the page "hangs", the file is still correctly uploaded with no evident indication of corruption or similar side effects.

For these reasons, I am inclined to think that you may have some "hidden" process running when the file gets uploaded that may conflict with the normal upload page behavior. I would check the library for any attacked event receiver/workflow that may introduce a delay/deadlock during the initial file creation.

  • 1
    Turned out to be a connection issue where the SharePoint servers were unable to connect to the Workflow database. This caused the issue where files could be uploaded to libraries, but any library that had a workflow attached to it would give the issue described in my question. Thanks!
    – Tom
    Jul 4, 2016 at 21:35

If you have an access on the master page than try to edit meta tag for http-equiv in the header & replace the content to IE=9 or IE=Edge.

Please check below line to replace the content.

<meta http-equiv="x-ua-compatible" content="IE=9">
<meta http-equiv="X-UA-Compatible" content="IE=EDGE"/>
  • Thanks for the suggestions, but none of the affected libraries or their site collections use a custom master page. Correct me if I am wrong, but wouldn't the issue manifest in all libraries if the problem existed in the master page? The odd thing here again is that it is only affecting a handful of libraries. I have the access to edit master pages, but technically it's a production environment (and I can't seem to recreate the issue in our test environment).
    – Tom
    May 31, 2016 at 20:05
  • So you are saying that it is not working for only one library. Please correct me if i am wrong.
    – Hardik
    May 31, 2016 at 20:11

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.