A lot of times LightSwitch customers will run into an error in the product and post a question on the forums but the LightSwitch development team needs more information about the error. This blog post describes how you can help the LightSwitch development team determine the source of those kinds of errors you may encounter. Unexpected errors (or exceptions as we call them) within the product can manifest themselves either by an error message, a crash, lack of response (hang), or when an expected behavior doesn’t occur. By providing an exception stack trace in your forum posts, it provides valuable information to the development team and helps us help you.
Before beginning the process of debugging, you’ll want to follow the necessary steps in Visual Studio or your LightSwitch app that reproduce the exception but stopping just prior to the last step that actually causes the exception. If you attach and debug prior to all these steps you may encounter a bunch of exceptions that are unrelated to the issue or performance of the process may be degraded enough that will make you annoyed. So just get to the point right before the exception occurs and then follow the instructions below.
The next step is to identify which process to debug. This handy flowchart can help you determine which process you should be attached to in order to retrieve the exception stack trace:
Note that if the issue you’re investigating occurs within your running application while you are running it from within Visual Studio via F5, Visual Studio will automatically be attached to both the client and server processes. In all other cases, you’ll need to manually attach to the process. Of course, if the issue occurs within Visual Studio itself, you’ll need to launch another instance of Visual Studio to attach to the original instance since a given VS process cannot attach to itself.
To manually attach to the process, go to “Tools –> Attach to Process…” in Visual Studio.
In the dialog that opens, select the name of the process as indicated by the flowchart above. This will only allow you to attach to the process if it is running on the local machine. If you want to attach to a remote process (for example, attach to the IIS process on a remote machine), you’ll need to follow the instructions in this MSDN article: Setup Remote Debugging. If the process is hosted on a machine you don’t have access to, like Azure, you won’t be able to follow the debugging instructions described in this post. Instead, you’ll need to use diagnostic tracing as described in this post: Diagnosing Problems in a Deployed 3-Tier LightSwitch Application.
Now that Visual Studio is attached to the process, it needs to be properly configured to break on exceptions in order to see the stack trace of the exceptions.
The first thing to do is to ensure that VS is configured to debug code that you don’t own. Visual Studio has a feature called “Enable Just My Code” that is enabled by default which prevents you from debugging code that isn’t yours. To turn it off, follow these steps:
This will break on all exceptions of that category. A lot of times there will be exceptions thrown that are irrelevant to the actual issue. These are normal and are handled by the LightSwitch code. If you know the specific exception type that you want to break on, you can configure this dialog to break only on that exception type by drilling into the Common Language Runtime Exceptions node and finding the exception or by clicking the Find button and searching for it that way.
You’re now ready to do the final step in Visual Studio or your LightSwitch app that actually causes the exception to occur. Once you do that, you’ll see an exception message appear in Visual Studio that looks like this:
Or like this if you’re debugging an HTML client:
As mentioned earlier, there can be exceptions that are thrown that are properly handled by LightSwitch and irrelevant to your actual issue. You’ll want to work with someone on the LightSwitch development team via the forums or e-mail to determine which exception is the one that is relevant. If you know the exception is not relevant, you can continue execution by clicking the “Continue” button.
Paste that text along with the other exception detail you collected into the text editor. You’ve now collected enough information to pass along to the LightSwitch development team. Of course, along with the exception information, you should still describe the set of steps that reproduce the issue.
Then follow the steps to reproduce the issue again. This time it will provide the friendly function names in the stack trace which is much more useful. Be sure to revert your changes to the default.htm file when you’re done debugging.