When adding or editing a page in a SharePoint Pages library we get the following exception:
[COMException (0x81020016): Item does not exist
The page you selected contains an item that does not exist. It may have
been deleted by another user. Click "Home" at the top of the page to return
to your Web site.]
at Microsoft.SharePoint.Library.SPrequestInternalClass.RenderColumn.
The weird thing is, when we first do "Check in" and then click the Publish button it works perfectly. But clicking "Publish" directly generates theis error, BUT NOT ALWAYS!
The Pages library has publishing and item planning on, NO workflow (seeing as the person who adds / edit pages is also the approver) and Major/ Minor versions.
We use a content type derived from publishing page and a custom PageLayout.
I'm sure you would have already checked this but is there any more information in the ULS logs?
Also have you tried setting the debugger to break on all exceptions and does this give you more information? Go to Debug, Exceptions and tick Common Language Runtime Exceptions. Then go to Tools, Options, Debugging and untick Enable Just My Code. Finally attach to w3wp.exe.
If you are running Windows Server 2008 you could also try taking a dump file at the point the debugger breaks above. ADPlus might help if you are running Server 2003 but I don't have experience with it. You should then be able to open the dump file with DumpChk or WinDbg.
Edit: As discussed in the comments, this is code deployed to production that can't have its service interrupted. The only way you could create a dump file is programmatically. Have a look at this question I asked that will hopefully help you if you need to go down this route.
Other things to try if you don't want to get down and dirty with debugging is to try deploying your custom bits to a clean server. See if you can still reproduce the problem or if it changes.
I am assuming that you are using load balancing with 2 web servers.
The fact that it does not happen always points to there being a difference between the servers.
There are then a few things that you could check:
Are all the versions and service packs are the same on both machines
Have any of the servers had beta software installed
Is your code the same on both servers
One thing you could do to test without taking the system down: Is to remove the first web server from the cluster see if the error occurs, then add it back and do the same thing with the second web server.
Related
I am trying to install IIS on my Windows 8.1 laptop and followed the directions at Microsoft for installing IIS. But when I type localhost, instead of getting the IIS start page, I get a blank page.
When I do Windows + R and type services.msc, the resulting list of services is long but does not include Internet Information Services.
When I look at the Windows filesystem, I do find the inetpub folder with four subfolders, including wwwroot. In the wwwroot folder is the iisstart.htm file that is supposed to display when I type localhost into my browser.
I have read that one possible problem is that both Skype and IIS want to use Port 80 and there is a conflict. So I decided to try to change the default port for IIS, but I found that I don't appear to have the IIS Manager on my system. When I go to Administrative Tools, Internet Information Services Manager is not on the list of administrative tools.
I added both the HTTP Redirection module as well as the IIS Management Service on top of the initial basic installation that Microsoft described. Still no luck getting IIS working or IIS Manager to appear.
I have tried to research this problem of getting IIS to work on Windows 8.1 with no success and am at a loss. Suggestions welcome!
In Control Panel --> Programs --> Programs And Features --> Turn Windows features on or off -> Internet Information Services -> World Wide Web Services -> Common HTTP Features -> Static Content.
Also make sure .NET Extensibility 3.5 and .NET Extensibility 4.5 are checked.
Major fail by Microsoft. Why the hell would they turn off the most basic features by default. Go to Turn Windows features on or off (just search "features"). Look in IIS, WWW, Common HTTP Features. See attached image.screenshot
I have solved a couple of my problems.
I installed several more IIS modules: Static Content, IIS Management Console, and HTTP Errors.
I am now am able to find the IIS Manager in the Administrative Tools list and can use the IIS Manager.
Also, when I pressed Windows key + R and typed in services.msc, I still don't see Internet Information Services in the list. However, I do see "World Wide Web Publishing Service" in the list and it is shown as running. A page at Microsoft's Technet site indicates that it is related to IIS.
The HTTP Errors module gave me an error page rather than a blank page when I typed in localhost and also when I typed localhost/filename. This proved a HUGE help, because the error page identified the problem as a permissions issue. I thought I had dealt with the permissions issues, but this error page made it apparent that I had not.
When I typed in localhost, I got the permissions error. When I typed in localhost/iisstart.htm, I got the proper display of the file. When I created a simple .htm file, statictest.htm, and placed it in the wwwroot folder along with iisstart.htm, and typed localhost/statictest.htm, I got the permissions error.
So since one of the files was working and one wasn't, I decided to compare their permissions. (You do this using the File Explorer. Right click on the file, click on Properties, click on Security Tab. To make changes, click on Edit.) I saw that the successful one had a user listed that the unsuccessful one did not. So I added a user for the statictest.htm file to the permissions list with full control. That solved the issue for that file and it displayed normally.
I now am back to getting a blank page when I type in localhost. It must not be a permissions issue, because otherwise I'd get the permissions error page. I'm not sure what the cause of the blank page is. But as long as I can get files to display when I give their name, I am happy enough.
I am happy to report that my PHP installation is also working, at least as judged by the fact that the phpinfo() function displays properly.
So to sum up: if you are having problems getting IIS to work on Windows 8.1, try adding more IIS modules and make sure your permissions are in order. I think the most important ones to add are Static Content and HTTP Errors. Also, of course, CGI if you are going to use PHP.
I know this is an older post, but in case anyone, like me, already had "static content" enabled, there was one other thing that needed to be done to resolve this issue.
Under "Programs and Features" -> "Turn Windows features on or off"
Expand "Internet Information Services" -> "World Wide Web Services" -> "Application Development Features"
Make sure that "ASP.NET 4.5" (and if needed/installed 3.5) are selected. This should automatically check ".Net Extensibility" for the selected version, and it should also enable ISAPI filters and Extensions.
By default (for me at least) these options were not turned on when I enabled IIS. I was getting a 500 error in IE if I had "Show Friendly Error Messages" turned on in IE, but if I turned that option off, I would get a completely blank page.
For me, the reason was that I had two different HTTP handlers in the config with the same name. I didn't get any errors, just blank response.
I'm guessing that some other parts of the configuration may result in a similar behavior. Try commenting out some parts of Web.config file in case you cannot figure the problem out.
Same issue.
Win 10 upgraded from 7. Default documents server blank and without error.
Static Content and Default Document features already enabled.
I resolved by disabling both features, rebooted and tried(received error 404), enabled both features, rebooted, pages served properly.
For me, I was using Windows Server 2008 on an Azure machine, it was missing some packages which can be installed using "Web Platform Installer", and then search for "recommended server configuration for web hosting providers"
I encountered the blank page problem as well on IIS 8.5 on Windows Server 2012 R2.
I had StaticContent installed as Windows feature.
What finally fixed it for me was changing the Path Type of the StaticFile Handler under [IIS Manager -> Server on left pane -> Handler Mappings -> StaticFile] from "Unspecified" to "File or Folder".
You can also change this on a per web site basis instead of the entire server (but I don't really see a reason why to do so, as it breaks pretty much any page). Make sure, however, that the site does not have an overriding setting for the StaticFile handler, as the site scoped one is preferred over the global one.
The SharePoint install is a SP2010 install on a 2008 R2 server. Everything is fully patched. I am running the SP Designer on the SharePoint Server directly.
I have a workflow which is intended to send an email when a new document is created in a custom list. I have deliberately kept the workflow very simple in order to illustrate this problem.
After creating this single step workflow in SP Designer, I click "Check for Errors" and SP Designer reports "The workflow contains no errors".
I then click "Publish" but the Workflow Error dialog is displayed with the message
Errors were found when compiling the workflow. The workflow files
were saved but cannot be run.
Clicking the advanced button reveals more information:
Could not publish the workflow because the workflow configuration file
contains errors
Any suggestions gratefully received
I'll share what fixed it for me - deactivating all workflow features at the site collection level (that is, Workflows, Three-state workflow, Publishing Approval Workflow) and then reactivating the features. I was then able to publish my workflow. This post helped, not sure whether this only works for 365 though, but it's sure worth trying first if you are considering a reinstall.
after googling for quite some time, i think it's an authentication issue. How is your SharePoint set up? Do you use HTTPS for authentication? If so check out this article.
I know this error message from sharepoint. I got this by dealing with multiple lookup fields refering to other lists. Even when I check the worfklow for errors SharePoint says that its all fine but i can't publish it at all.
Try to build a new Test-Site on your Site Collection. Build a Custom Document Library, leave it standard and then set up a new simple workflow just sending a mail.
Fill out the needed fields in mail only using simple values. Send to your mailadress, simple mail subject and simple mail body.
Set the workflow to run only manually.
Try to publish the workflow.
When this is working, then compair to your existing workflow and change your values by trail and error.
After doing a clean install of the OS and SharePoint, workflows are working flawlessly. I can only conclude that the problems were caused by left over registry settings from MOSS 2007. Thanks for the suggestions that people made.
This could also happens if you chage the URL of the web application, all you have do is click the Design button from the library itself.
when changinf the URL from http://server/Site to example: http://server.xx1.net/site, and you try to publish it tries the old url.
what helped in my situation is changing from start workflow automatically to manually.some times answers for critical situation is very easy. hope it helps, many thanks
I ran into this problem and after digging for days and folks suggesting to rebuild the servers, disabling and re-enabling site features, remove previous workflow versions, etc. and trying everything except rebuilding the servers (not practical for clients production environment). I decided to try some tests and found that this issue was only happening on one particular list no matter how simple or complex the workflow was... And when I would check the box for start automatically on item create (or when item changed) it would fail to publish and give the error above, but if I published it with just manually start worked fine. Finally after deleting views and some more testing, I discovered that there was over 240+ columns in this list (I did not create it...) and 50+ workflows set to run on create... Thankfully I have a test environment I built out for the client so I sync'd the Site Collection database back to test environment from Production re-ran my tests and got same error... So what resolved the problem and what was the ultimate cause of the problem, there was to many columns defined in the list and I had to delete several columns to publish the workflow in the test environment. This actually issue translates into the there is a limit in SQL Server on how much data the list can store each type of column takes up so much space read more about it here:
https://technet.microsoft.com/en-us/library/cc262787(v=office.15).aspx#Column
So what I did in production was worked with my client to determine how to break up the list into multiple lists and have relationships between them, thus moving some of the columns and data to another list (Think database/list normalization)... I hope this solution helps someone.
I have a customer using the Access 97 runtime to support part of their product. Ideally, given the budget to do so, I would have replaced that dinosaur by this point, but that isn't an option today. I am not the system's original author, but am attempting to provide ongoing support.
To distribute this to their customers, they bought the Office 97 Developer Edition Tools, and once every few years they go through its Setup Wizard to package a new distribution.
This time, the Setup Wizard appears to reach a point where it wants to do something with AXDIST.EXE, and instead puts up a dialog box saying only "Path not found". The only reference I've located on the web is a tantalizing glimpse of a page from a domain that no longer exists, where Google has purged the cache retaining only the sentence that appears with the search result. It isn't enough of a hint to help me...
(Edit: Aside from lots of reported issues caused by AXDIST.EXE itself, or installations that are trying to use AXDIST.EXE in some way, that is. Our issue is a problem during the creation of a setup package using the ODE setup wizard. Its own documentation only references AXDIST in one place, and does not contain the text "path not found" at all.)
(Edit 2: Further investigation reveals that AXDIST.EXE itself is not the culprit. Removing that file from the setup wizard's list caused the wizard to stop on the next file in the list. There does not appear to be any significant differences between the description of the file on which it stopped, and the dozen or so files listed above it that were successfully processed. I'm guessing at this point that the resolution is going to be manually recreating the template from scratch, which would be a lot easier if it weren't trapped inside a horrible UI and stored in the form of an Access database containing a bunch of undocumented tables.)
My question is this: What mistake did we make this time with the setup wizard, and how can we fix it?
The issue turned out to be related to a feature of the Access run time that was explicitly listed in the setup wizard, but should have been left for the wizard to infer.
My general advice to anyone also stuck with dealing with the wizard would be to go back to the start and review all the settings carefully and methodically.
I am getting a random web part error, it works one refresh and then not the next:
Web Part Error: One of the properties of the web part has an
incorrect format. Windows SharePoint
services cannot deserialize the Web
Part. Check the format of the
properties and try again.
The web parts have been on the site for a long time, and I have checked Micorsoft Support, http://support.microsoft.com/kb/826786 . And it is not a permision error becuase it has been this way for a long time. The only thing changed in regards to webparts was going into Site settings > Web Parts > New and selected some webparts that were not in the list and I think I also Checked the ones that are having this random error and clicked "Populae Gallery". Any body have a clue?
This could also be because of insufficient disk space on the server where SharePoint is hosted. http://www.sharepointblogs.com/vipul/archive/2006/09/25/webpart-error-due-to-space-crunch.aspx Check the available disk space.
Hope this helps.
Have you tried rebooting your server. I have just recovered from this exact problem. One of my frontend servers ran out of disk space yesterday and I recovered 10Gb of it, however this didn't rectify the error I was receiving when trying to view or add page viewer webparts until I rebooted it. All is perfectly fine now.
but try doing this:
Go the central administration
operations
service accounts
Web application pool (radio button)
webservice (drop down); select windows sharepoint services web app
application pool (second drop down); select the site that the problems occurs on e.g. home_port_80
user name (text field): type in the account info you have used during sharepoint post installation configuration
password: at last type in the password.
hope it helps
Another thing that can cause this is an "undocumented feature" in SPD that splits the Web Part properties across two lines, like this:
<FrameType>
None</FrameType>
Just removed the line break, like this:
<FrameType>None</FrameType>
and everything started working again ...
I wrote a custom web part for SharePoint 2007 that loads an existing user control. One of the things the user control does is an asynchronous upload of a file via FTP. I'm using a third-party FTP library that has BeginUpload/EndUpload methods for async file transfer. I also have an update panel in the user control that I use to display a running total of the number of bytes that have been transferred, based on an event raised by the FTP library. I've added all the necessary AJAX settings to web.config.
Everything works great if I run the user control by itself from a separate project. But when I access the web part that hosts the control and try an upload, the FTP library transfers about 64 KB and then the thread it's running on dies. The message I get in the VS output window is:
The thread 'Win32 Thread' (0xf34) has exited with code 0 (0x0).
I get several of those and then the FTP library throws an exception (basically it times out), the IIS worker processes blow up, and the whole thing comes to a halt. Is there something special I need to do in my SharePoint configuration or the web part to make this work? It seems to be something about SharePoint since the same code works fine if SP is out of the picture.
I submitted this problem to Microsoft SharePoint developer support and they were able to reproduce the error with the FTP library I'm using, which comes from ComponentSpace. Normally what I'm trying to do is possible, but for some reason it just didn't want to work.
Their solution was to save the file on the web server by doing a Request.Files(0).SaveAs and then doing the FTP upload. Not ideal, but it gives me the progress indicators I wanted.
Chris Tybur, I have tried their FTP component and found many bugs. I would not recommend ComponentSpace's FTP