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.

Exception Lead-In

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.

Attaching to the Process

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:

image

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.

image

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.

Configure for Debugging

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:

  1. Go to Tools –> Options.
  2. If necessary, click the “Show all settings” check box at the bottom of the dialog if the “Debugging” node doesn’t show up in the tree.
  3. In the Options dialog, navigate to Debugging –> General in the tree.
  4. Ensure that the “Enable Just My Code” check box is not checked.

image

 

The next thing is to configure VS so that it will break when an exception is thrown.  To do this, open the Exceptions dialog: Debug –> Exceptions.  In the Exceptions dialog, find the category of exceptions you want to break on and check its check box in the “Thrown” column.  For server and Silverlight client debugging, you’ll want to use the Common Language Runtime Exceptions; for HTML clients, you’ll want to use the JavaScript Runtime Exceptions.

image

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.

Reproduce the Exception

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:

image

Or like this if you’re debugging an HTML client:

image

 

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.

Collect Exception Information

Once you’ve found the exception, click the “Copy exception detail to the clipboard” in the exception window if it’s a .NET exception and paste the result into your favorite text editor.  If it’s a JavaScript exception, there won’t be a link to do this so just skip that step.  Now, you’ll still need to collect a little more information since that exception detail won’t include a detailed stack trace.  Click the “OK” or “Break” button in the exception window to dismiss the window.  Open the Call Stack window in Visual Studio: Debug –> Windows –> Call Stack.  Select all of the lines in it (Ctrl+A) and copy it to the clipboard (Ctrl+C).

image

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.

HTML Clients

If you’re debugging a JavaScript exception, the stack trace will probably have a lot of single letters for function names.  This happens because you’re app is configured to use the minified versions of the runtime JavaScript files.  To provide a more informative stack trace, change your default.htm file of your HTML client and remove “.min” from all of the filenames of the referenced scripts.

image

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.