Steps to Log all .net Exceptions to a Log file with Debug Diag 2.0
Sometimes it's good to know what exceptions a process like w3wp.exe is throwing. ASP.net is pretty good about making its complaints known in the form of exceptions. Many or perhaps most exceptions can be ignored. But if you're trying to troubleshoot a mysterious problem that isn't leaving clues in the event logs, this may be a good way to begin to unravel the problem. Sometimes you can see them logged in the Application event log—but usually not. Sometimes you can see them in the ULS logs of SharePoint servers—but usually not. You could get the developer can add some additional instrumentation to the code to log the exceptions to a log file. Or you might use Todd Carter's SNAP tool to see what .net exceptions are being thrown. Or you can, as I'll suggest here, try to use Debug Diagnostics 2.0 to log all .net exceptions to its log file while reproducing a problem.
Install DebugDiag 2.0 on the server. Location: http://debugdiag.com
If you can't get permission to install it with the .msi, consider the xcopy option here.
Launch DebugDiag 2.0 Collection
Confirm that "Crash" is selected as the rule type and click NEXT
Player that I am in the SharePoint universe, I tend to focus on a specific w3wp.exe that corresponds to a specific IIS Application Pool.
Assuming you know which Application Pool to focus on, select "A specific IIS web application pool."
Select the Application Pool in focus and click NEXT
For good measure I like to log some of the native code exceptions (non-.net) as well as the managed/.net exceptions.
SharePoint uses both native and managed code. This will help give some insight into the native side.
So change action type to "log stack trace" and change action limit to a high number (like 9999 or 999999).
Click the EXCEPTIONS button
Click the ADD EXCEPTION button
On the left side, select CLR (.NET) 1.0 – 3.5 Exception
On the right side, set Action Type to "Log Stack Trace" and Action Limit to a high number (like 9999 or 99999)
Click the SAVE&CLOSE button
Feel free to change the Rule Name to something like "Exception logging for Application Pool XYZ" if you please.
Feel free to change the rule output location.
Place a bullet beside "Do not activate the rule at this time" and click FINISH.
If you want to have a "baseline" to have a record of which exceptions are "normal," right-click the rule, activate it, generate some activity on the website without duplicating the problem you're hoping to troubleshoot, deactivate the rule, and then proceed with the next steps.
It's probably a good idea to get additional debug information added to the log file.
To do so, expand the tools menu, select Options and Settings
Place a checkmark beside "Enable raw debugger logs. Includes debug output and engine messages."
Get everything as ready as possible to reproduce the problem. If possible, get to the point where you are one simple mouse-click away from reproducing your problem.
When you're ready to reproduce the problem, right-click your rule and activate it.
Reproduce your problem quickly
After you see your symptom or error message in the browser, deactivate the rule.
Find your new log files by clicking the icon of the manila folder. This will open the folder C:\Program Files\DebugDiag\Logs
The file you're looking for may have a name that looks something like this:
If your application is throwing several exceptions every second, doing this type of logging can really bog down the machine. Beware. And note these cool new features in 2.0 from the Tools > Options and Settings > Crash Rule Preferences tab. . .
More details here: http://blogs.msdn.com/b/debugdiag/archive/2013/10/02/did-you-know.aspx