While attempting to use SharePoint Designer to make some minor modifications to the editform.aspx page of a list I ran into a situation where the W3WP.EXE process on the SharePoint server would crash.
In the application event log on the SharePoint server I found the following error:
Faulting application w3wp.exe, version 6.0.3790.3959, stamp 45d6968e, faulting module kernel32.dll, version 5.2.3790.4062, stamp 46264680, debug? 0, fault address 0x0000bee7.
This really doesn’t offer much help. But what I did know I could reproduce the error easily by attempting to edit any aspx page in SharePoint Designer. I decided to load up Fiddler to take a peak at the HTTP requests to the server to see if I could find any clues as to the cause of the error.
With Fiddler running I could see that everything was loading fine into SharePoint Designer right up until it tried to call the GetAssemblyMetaData method on the webpartpages.asmx webservice. Once that request was made I immediately saw the w3wp.exe error in the event log and according to Fiddler all other request just appeared to hang.
Within Fiddler I could look at an XML representation of the request. There I saw that the GetAssemblyMetaData method was taking a few parameters. One of the parameters was called assemblyName and was being set to microsoft.office.server.search, version=184.108.40.206, culture=neutral, publickeytoken=71e9bce111e9429c.
Interesting, why would SharePoint Designer be trying to get assembly meta data information from the SharePoint search assembly? I opened up my custom masterpage for the SharePoint site and found the following registration:
<%@ Register TagPrefix="SEARCHWC" Namespace="Microsoft.Office.Server.Search.WebControls" Assembly="Microsoft.Office.Server.Search,Version=220.127.116.11,Culture=neutral, PublicKeyToken=71e9bce111e9429c" %>
I did some research and from everything I can see I really don’t need that assembly registration in my masterpage. Once I removed this line from the masterpage I was able to load and edit the editform.aspx file within SharePoint Designer with no problems.
It is important to note that this issue didn’t surface until the December cumulative patches were applied bringing the environment to version 18.104.22.16835. Prior to that patch we were able to use SharePoint Designer without issue even when the masterpage had the SharePoint search assembly registration.
One other interesting point is that after this registration tag was removed I watched all of the calls SharePoint Designer made to the SharePoint server. The GetAssemblyMetaData method was never called. I really wonder what triggers SharePoint Designer to call that method on the SharePoint search assembly registration and not on any other assembly registration.
I would love to hear from anyone who has had a similar experience or might be able to shed some light on the GetAssemblyMetaData method call from SharePoint Designer.