Sometime during development on Enterprise Portal we get error:
Of course this error is not so descriptive and if there is no information in event viewer it is almost impossible to know what is going on.
The easiest way to get more information is to enable debugging on our page. To do it you need to:
1. Copy web.config (located in Local_Drive:\Inetpub\wwwroot\wss\VirtualDirectories\Port_Number) to save place
2. Edit web.config
3. Set CallStack="true" in line <SafeMode MaxControls="200" CallStack="false" DirectFileDependencies="10" TotalFileDependencies="50" AllowPageLevelTrace="false">
4. Set debug="true" in line <compilation batch="false" debug="false">
5. Set customErrors mode="Off" in line <customErrors mode="On" />
At this point when you access back the problematic page you should see more descriptive error and what is more important there is call stack. From this call stack most developer would be able to find problematic code and fix it. If it still does not help then we can debug code behind the web part. To debug the C# code we will need to have debugger installed on Enterprise Portal server. In my case I have Visual Studio 2008 installed.
To debug I do following:
1. Editing the web.config file as stated above
2. In Visual Studio 2008 go to: Tools - Attach to Process from the menu
3. Make sure the options Show processes from all users and Show processes in all sessions are enabled (checked)
4. In the list of processes located the process w3wp.exe and attach to this process (If you have more than one w3wp.exe process listed, see the appendix at the end how to determine the correct process)
5. Open problematic web control code from C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\12\TEMPLATE\LAYOUTS\ep (We are interested in file with extension .cs)
6. Put your breakpoint in opened control
7. In IE go again to problematic page
How can I determine the correct w3wp.exe process to attach to?
The Microsoft SQL Server Reporting Services 2005 are hosted in the Microsoft Windows Server Internet Information Services (IIS). Therefore the process to attach to for debugging is the IIS Worker Process (w3wp.exe). As IIS is starting at least one Worker Process per Application Pool, more than one w3wp.exe processes are usually running on a Windows Server.
In order to see what Worker Process is serving what IIS Application Pool tools exists:
- On Windows Server 2003 (IIS 6.0) run: iisapp.vbs
- On Windows Server 2008 (IIS 7.0) run: appcmd.exe list wp
The output of the tools looks as follows:
W3WP.exe PID: 2056 AppPoolId: AxReportServer
W3WP.exe PID: 5092 AppPoolId: EP - 39014
C:\Windows\system32\inetsrv>appcmd.exe list wp
WP "6916" (applicationPool: SharePoint Central Administration v3)
WP "1356" (applicationPool: AxReportServer)
Once identified the correct w3wp.exe process (based on the Application Pool) use the PID (Process ID) to attach to the correct w3wp.exe process.
--author: Czesława Langowska
--editor: Czesława Langowska
--date: 17/Nov/2010