The easiest way to create modern business applications for the Cloud and Office 365
There are a number of times when a LightSwitch application works perfectly on a developer’s machine, but as soon as it has been deployed to an Internet Information Services (IIS) machine, it no longer works. Problems can range from IIS not being configured correctly to the database connection string being incorrect. Or an assembly might not have gotten deployed to the IIS machine. I would like to share a few debugging techniques that I regularly use in order to help system administrators diagnose problems in their deployed applications. For more information on how to configure your web server and how to deploy a LightSwitch application, see Beth Massi’s deployment guide.
Before I continue, I’m going to set your expectations correctly. There definitely isn’t a silver bullet that is going to solve any and all problems you will hit when deploying your application. However, what I’m going to provide is a list of steps you can use to diagnose the most common problems we’ve encountered. These steps are the first thing I use when someone stops by my desk and says “I’m having a problem with my application”. If (and when) these steps aren’t able to help you diagnose your problem, they will at least provide you with some good information to take to the forums where others may be able to assist you.
In the LightSwitch world, the dreaded red X is analogous to the Red Ring of Death on an Xbox 360. OK, so a red X in LightSwitch isn’t as catastrophic. You don’t have to send your app away for a month to get it repaired. But it is a major indication of a problem in your application. When your application fails to load data successfully, the screen will display a red X and the tool tip will say “Unable to load data. Please check your network connection and try loading again.”
These red X’s really mean that an exception was thrown by executing the query.
So what do you do?
A little known secret about LightSwitch is that the server has a Diagnostics subsystem integrated with ASP.NET tracing. LightSwitch’s Diagnostics subsystem is a lot more powerful than just telling you what exception was thrown when issuing a query. You can use it to trace through the actions that were requested of the server, and what steps the server took in response to each action. So even if things seem to be working, you can get more information about what your application was actually doing.
Diagnostics is disabled by default when you create a new LightSwitch application. This is for both performance and security reasons. The performance reason is kind of self-explanatory. Even simple tracing on the server will lower its throughput. The security reasons are because any registered user of your application can get to the diagnostics log when it is enabled and when you enable remote machines to see the diagnostics.
There are 5 app settings that control the behavior of the Diagnostics subsystem:
There are two ways to enable LightSwitch Diagnostics.
To change the Web.config, switch your Solution Explorer to “File View”.
Then click on the “Show All Files” tool bar button.
Under the “ServerGenerated” project you will find the “Web.config” file, which you can edit the settings under “configuration/appSettings”.
Open IIS Manager and find your web site on the left side. On the right, double click on the “Application Settings” icon under the “ASP.NET” heading.
You will see the Microsoft.LightSwitch.Trace.* settings which can be edited to your desired settings.
Once you have enabled diagnostics, you can now inspect the information that is being logged in your application. Remember, any request before tracing was enabled won’t show up in the trace information. So you may need to reload your app in order to get the trace logs populated. ASP.NET provides a web site you can load to view the trace log. The URL of the web site is: <Path To LightSwitch App>/trace.axd. So in my Contoso app above the URL is http://MyServer/Contoso/trace.axd. Navigating to this site shows me the following:
As you can see, LightSwitch made 4 service requests when it was loading my application. The first is a call to “GetAuthenticationInfo”. This is used to see if Access Control was set to None, Windows, or Forms. If it is Forms, LightSwitch displays a Log In screen before displaying the application. The second is the call we are interested in: “Customers_All”. This call executes the Customers query. The last 2 are service calls to get whether the current user can Insert, Update, and Delete certain entity types. In my app this was for the Customer and Order types.
Since I know that the “Customers_All” call is the one causing me problems, I click on its “View Details” link to drill into that call. And here I am greeted with a big red message:
I see an exception has occurred “Login failed for user” and the name of the account my IIS Web Application is running under. This tells me that my application tried using the current account to log into the SQL Server database. However, that account isn’t set up as a user on my database. I forgot to change my connection string when I deployed. It was working fine on my development machine because it was running under my account. But once I deployed, it is now running as a different account that doesn’t have privileges to access the database. Changing the connection string to use valid credentials fixes this issue.
I have just walked you through how to diagnose a very common issue: the database credentials no longer work once the application is deployed out into the wild. However, doing the steps outlined above can help diagnose almost all red X issues popping up in your application. You may not immediately see the problem, like we did above, but it will give you information to build up your knowledge on what is going wrong. Using the Diagnostics subsystem is a trick that every LightSwitch developer should have up their sleeve.
Please be aware that tracing, especially remote tracing, should only be used when debugging and deploying your application. When you move your application into production, be sure to set Microsoft.LightSwitch.Trace.LocalOnly to ‘true’ in your application. Also, in production, tracing should only be enabled if you really need it.
So if the red X error described above is ‘dreaded’, the “GetAuthenticationInfo” error message can probably be described as ‘execrated’. (Don’t worry; I had to look it up in a thesaurus.) Many hours inside and outside of Microsoft have been spent trying to debug this error. The problem is, there isn’t just one issue that causes this error. There are seemingly endless issues that cause this error. The reason is explained above. ‘GetAuthenticationInfo’ is the very first service request that LightSwitch is trying to make when your app loads. Thus, if there is any configuration issue with your IIS machine, web app, virtual directory, etc. this error is going to be displayed. Unfortunately, using the diagnostics tracing outlined above isn’t going to help in this situation. More than likely, the service call isn’t even getting into LightSwitch code. As such, our diagnostics isn’t able to log information, since it isn’t getting that far.
So in order to diagnose the problem here, we will use another tool, Fiddler. Fiddler is a tool that every web developer and IT administrator should have at their disposal. It logs all web traffic between your computer and the IIS web server. It will do the tracing that the LightSwitch diagnostics can’t do. Download Fiddler and start the program on your client machine. Then try to load your LightSwitch application again. You should see web requests and responses in Fiddler.
When you start Fiddler, you will see the requests on the left side. To look at the information being exchanged, click on the “Inspectors” tab at the top, and select the inspector for both the request at top and response at bottom. My 3rd request, which was for ‘GetAuthenticationInfo’, returned a ‘500 – Internal Server Error’ response. The text inside shows what the server responded with. Here is says
An application error occurred on the server. The current custom error settings for this application prevent the details of the application error from being viewed remotely (for security reasons). It could, however, be viewed by browsers running on the local server machine. To enable the details of this specific error message to be viewable on remote machines, please create a <customErrors> tag within a "web.config" configuration file located in the root directory of the current web application. This <customErrors> tag should then have its "mode" attribute set to "Off".
An application error occurred on the server. The current custom error settings for this application prevent the details of the application error from being viewed remotely (for security reasons). It could, however, be viewed by browsers running on the local server machine.
To enable the details of this specific error message to be viewable on remote machines, please create a <customErrors> tag within a "web.config" configuration file located in the root directory of the current web application. This <customErrors> tag should then have its "mode" attribute set to "Off".
This error message tells us that an error occurred, but the server doesn’t want to display the details of the error. So we need to configure the server to tell us the error. To do this, you can modify your Web.config to add the “customErrors” section it says to add and then re-publish your application. Or you can modify the settings in IIS Manager. In IIS Manager, navigate to your Web Application on the left side. On the right, under "ASP.NET”, double-click on “.NET Error Pages”.
On the far right side, under the “Actions” group, click on “Edit Feature Settings…”
In the Edit Error Pages Settings, select either “Off” if your client is on another machine, or “Remote Only” if you are using the IIS machine as the client.
Now that custom errors are turned off, hit your application again and look at the Fiddler trace. You should still get a “500 – Internal Server Error” message, but the response should give you better information on what the internal server error was. Now I get:
As you can see, the error message is “Unrecognized attribute 'targetFramework'”. Doing a quick Bing search on that error message tells me that I need to make sure the App Pool that is serving my site is set to the 4.0 framework. So to fix this error, I right click my “Contoso” Web Application in IIS Manager and select “Manage Application” –> “Advanced Settings”. This allows me to change my Application Pool from “Classic .NET AppPool” to the correct “ASP.NET v4.0”. After doing that, I reload my application and everything is working again. (Note: When using LightSwitch deployment, the Application Pool will be set correctly. However in my case someone else accidently changed it.)
As I’ve said, these two diagnosis techniques may not solve every issue you can run into after deploying your LightSwitch application. But they are great first steps that can be taken to help you determine what the error you are running into is. And hopefully with that information you will be able to fix the problem yourself, go to Bing and search on the issue, or go to the LightSwitch Forums and use that information to get a faster resolution.
Thank you for a great blog post.
This is exactly what is needed to help us to find when we have Red X issues.
You did a great job with posting all step by step info on one place.
Thank you again
I'm running fiddler and am getting similar errors. However where you are getting a 500 error on the GetAuthenticationInfo I am getting a 404. Any ideas on this?
@Spoonstomper - LightSwitch uses WCF Ria Services underneath the covers. WCF Ria Services will return a 404 whenever an exception occurs while trying to initialize the service. Here is some information on how to diagnose Ria Services - msdn.microsoft.com/.../ff426913(VS.91).aspx. Also, maybe enabling WCF tracing might lead you to some more information - msdn.microsoft.com/.../aa702726.aspx.
If all else fails, attaching a debugger to the w3wp.exe process and breaking on exceptions is usually my last resort to figuring out what is going wrong.
When I take a LightSwitch application that is working on one computer and then try to run the Visual Studio project on another, and I get the "red X", I can fix it by opening up one of the Entities under Data sources, making a small changes, saving, then changing it back.
This will dump any sample data you may have had but it fixes the problem.
This is a really good, well-detailed article, but it's all about LS web applications. What would you suggest for desktop (so-called 2-tier apps, even though I know that they're really still 3-tier), other than make it a web app?
Where can we look for these problems that you decribed when the app is not a web app.
@Yann - Some of these tips and tricks work for 2-tier deployed apps as well. The diagnostics with "trace.axd" works but the trick is to find the port number the vslshost.exe process is listening to. I usually find the port number by going to the Task Manager -> Resource Manager -> Network tab and look under "Listening Ports" for VslsHost.exe. Once you have the port number, open a browser and navigate to "http://localhost:<port>/trace.axd".
Along those same lines, you can open your browser and just navigate to "http://localhost:<port>" and your LightSwitch app should load in the browser. Now you can use Fiddler in the same ways I described above. (Sometimes to get Fiddler to recognize localhost requests I need to say "http://localhost.:<port>" [note the period after localhost].) In order to get customErrors="off", you need to edit your web.config.
Really helpful, thanks...it takes us one step closer to the solution whereas before I was on a slide going backwards!
Excellent post! This helped me a lot. I had to change my targetframework to ASP.NET v4.0.
For those seeing the error: Load operation failed for query 'GetAuthenticationInfo'. The remote server returned an error: NotFound.
I was recently testing deployment scenarios under IIS and ran into this error. I thought I would post my findings and eventual solution in case you find yourself in the same position…
As of 10/6/2012, my test server was Windows 2008R2 (latest service pack) with SQL Server 2012 Standard. The IIS role was not installed.
I downloaded and ran WebDeploy 4 for the LightSwitch 2012 provisioning without SQL Express (since SQL Server was already installed on the same server). This obviously enables the IIS role.
I had no problem publishing my LightSwitch 2012 Web application along with the database.
However, when I attempted to run it, I received the error:
Load operation failed for query 'GetAuthenticationInfo'. The remote server returned an error: NotFound.
Same thing happened when attempting to browser to the web app from the server locally. After taking a quick look with Fiddler, I noticed that the failure appeared to be related to a missing Authentication request ending with ".svc". I took a quick look into the IIS script mappings and noticed that there was no mapping for anything with the extension ".svc".
Apparently, this is all realted to the ASP.net 4 dll mappings required to run the LightSwitch application. The solution (for me) was to simply go into Add/Remove programs and repair the .Net 4 extensions and .NEt 4 Client installs.
Afterwards, I noticed a whole bunch of new IIS script mappings created - including one ending in .svc.
Problem solved. After this, the LightSwitch app loaded and ran with no errors. Perhaps the order by which I enabled these components on a new Windows 2008R2 server (ie. SQL Server 2012, WebDeploy for LS 2012 – no SQL express) causes an issue with the .Net 4 IIS mappings required to support the LS application.
I hope this helps anyone running into a similar situation.
I am getting the dreaded: HRESULT E_FAIL HAS BEEN RETURNED TO FROM A CALL TO A COM COMPONENT when I start a LightSwitch app. Any suggestions?
I see you've asked the question in the forums
I've replied to you there. Hope that helps.
Thank you !!!!! What a life saver :)