First of all, you will need to turn off the custom errors. If you haven’t already done so, click here to find out how to turn off SharePoint Custom Errors
After you’ve done that, you will be able to get more information about your application errors straight from the error page that will be served from SharePoint.
If you’re developing with Visual Studio, what you will want to do is attach to the process that runs your application so that you can visually test the variables and stuff and get more information about your code from within Visual Studio.
In order to do that, bring up the “Attach to Process” dialog box, scroll down to w3wp.exe, select as many of that process instances as are running and click on Attach. Your Visual Studio is now attached to the process that runs your application and you can visually debug your code. You can use breakpoints just like you would do with any other application. And if your application crashes, you will be given more information in your Visual Studio debugger. (Note that you will first need to tick the bottom two tickboxes before you can see the processes that run your application. “Show processes from all users” and “show processes in all sessions” should both be ticked)
note1: Attaching to a process is easy. Either click on Debug (on your file menu) and then select Attach, or, for a much quicker approach, just press Ctrl+Alt+P simultaneously.
note2: Although attaching to all the w3wp.exe instances is not wrong, you could easily find out which of them is your actual process by following the steps below (notice that this only works for IIS versions 6 and before):
1. Go to your command prompt
2. Execute the following command: %systemroot%\System32\cscript.exe %systemroot%\System32\iisapp.vbs
note3: But what happens if you’re on a IIS7 machine or newer? Turns out that you can use a very nifty little bat file that you can find here in order to get the very same functionality. Just run it, and you will be displayed of all the running worker processes.
