I personally got this problem on my laptop a while ago where IIS and Skype where involved, and even if this time the customer reported two different applications involved (Visual Studio 2005 and Cisco IP Communicator), the symptoms where the same: with Visual Studio 2005 and Cisco IP Communicator running ad the same time, he was unable to debug his web application with the message “Unable to start debugging on the web server. Could not start ASP.NET or ATL Server debugging. Verify that ASP.NET or ATL Server is correctly installed on the server“. If he stopped the IP Communicator the problem went away; clearly a conflict between IIS and Cisco Communicator. Just to be sure we had a look at “netstat -a -b”, and found (as expected) that both applications were listening on the HTTP port TCP computername:http computername.domain.com:0 LISTENING 492 [inetinfo.exe] TCP computername:http computername.domain.com:0 LISTENING 3872 [Communicator.exe] Since I don’t know how Cisco IP Communicator works (and we can’t support third party apps anyway), we decided to change the IIS port to 81, but this time the customer was getting “Unable to start debugging on the web server. Unable to connect to the web server. Verify that the web…
-
-
Driver’s SQLAllocHandle on SQL_HANDLE_DBC failed
Another weird one I got this afternoon. A colleague from the Sql team asked my help about what looked an authentication problem is customer’s web application, while trying to connect to a Lotus Notes database: in short, the customer was developing his application with Visual Studio 2005 and was testing it with Cassini, and everything looked fine, but as you can guess the problem arose when he deployed the site on his test IIS. They got the error [IM005] Driver’s SQLAllocHandle on SQL_HANDLE_DBC failed. The first thought was about a permission problem, since as you may know one of the main differences between IIS and Cassini is that the latter is essentially a process which runs in the context of the account logged on the machine, while IIS is a service which runs under different accounts but with lower privileges. Ok then, to verify this hypotheses we made a quick change to the <processModel> section to have the worker process running under the customer’s account instead of the default ASPNET (he was testing on his local IIS 5.1 on XP). Well… same problem. So that could not be a security problem, ASP.NET was running as an administrator… ? The error…
-
Unable to “InitializeSecurityContext”?
Sometimes having fortune at your side can really save you the day (to say the least), and in developer support it can save you hours (of not days) of troubleshooting… With this premise, a couple of weeks ago I was helping a colleague from the Sql Server support team whom was struggling with an authentication problem one of his customers was having with Reporting Services: basically IIS was prompting them to login to access the application, but even entering the correct credentials those were refused, and after three strikes they were redirected to the standard 401 (unauthorized) page. While waiting for some logs I requested to the customer, I was building a repro for another customer I had at the same time (with a completely different problem, that was a weird runtime exception I’ll likely write about in another post), and one of the requisites was to have the application pool running under a domain account instead of the default NETWORK SERVICE: well… I got the same problem reported by the first customer! ? It worth mentioning that I was also using Integrated Authentication for the virtual directory, and interestingly, the problem disappeared if I was using a local account…
-
Your login attempt was not successful. Please try again
This time the customer was using the “Web Site Administrator Tool” wizard to create the authentication mechanism (based on SqlExpress membership) for his site. As usual everything was working fine on his development machine, but after deploying the application on the live web server users were no longer able to authenticate, and they got the message “You login attempt was not successful. Please try again.“, and in the event log we found a few messages like the following: Event code: 4006 Event message: Membership credential verification failed. Event time: 13/04/2006 13:23:30 Event time (UTC): 13/04/2006 12:23:30 Event ID: 89ff87b6e2d8490c9b873730e50af976 Event sequence: 3 Event occurrence: 1 Event detail code: 0 Application information: Application domain: /LM/W3SVC/1/Root/myapp-1-127894037524081250 Trust level: Full Application Virtual Path: /myapp Application Path: d:\inetpub\wwwroot\myapp\ Machine name: WEBSERVER Process information: Process ID: 5540 Process name: w3wp.exe Account name: NT AUTHORITY\NETWORK SERVICE Request information: Request URL: http://<web server ip>/myapp/login.aspx?ReturnUrl=/myapp/search.aspx Request path: /myapp/login.aspx User host address: <web server ip> User: Is authenticated: False Authentication Type: Thread account name: NT AUTHORITY\NETWORK SERVICE Name to authenticate: administrator The problem is that this error message is misleading; we found out that the…
-
Debugger not debugging, and Response.Redirect() not redirecting…
The customer was working on a WinXP machine joined to a domain, but had logged in using a local account (I’ve not tested if this may have contributed to the problem so this may be a useless information). Anyway to make things easy I connected to the faulting machine using EasyAssist to have a better look at the configuration: everything looked fine both in IIS and Visual Studio. Interestingly browsing the application from IE directly we found that even if he was using “http://localhost/app” the page was shown in the “Internet” zone (hence the debugger error). This usually happens when the application is created using either the IP address or the FQDN (Fully Qualified Domain Name) of the web server; to verify, we created a new test project as “http://localhost/test” but got the same debugging problem, and again the page belongs to the Internet zone. As a test we enabled “Automatic logon with current username and password” for the Internet zone and then the debugging started working fine. Talking about this with my team colleagues they suggested uncheck “Automatically detect intranet network” in the “Local Intranet” settings and enable the three remaining checkboxes; this because under some circumstances IE may…
-
Avoid UAC prompt in IE component
Wow, this has been a tough one I closed this afternoon. The customer has developed a custom IE toolbar to interact with their portal, and found that when running this on Vista, IE displayed a warning dialog asking the user’s consent to run an external program; in particular that was happening when the toolbar was calling a Web Service to retrieve some content from the web server. If for test we denied the permission to run the external problem, we got this error message: “System.Runtime.InteropServices.ExternalException: Cannot execute a program. The command being executed was “C:\Windows\Microsoft.NET\Framework\v2.0.50727\csc.exe” /noconfig /fullpaths @”C:\Users\Vista\AppData\Local\Temp\Low\ev4a0rzg.cmdline“.” The exception occurred when the SOAP client proxy tries to spawn the compiler to generate the type serialization assemblies the first time the web service is called. After the usual log analysis we setup a repro in a virtual machine, and we found that this was not an UAC issue but rather an IE Protected Mode problem (by the way, Protected Mode in IE is currently available only on Vista, so maybe this is why the customer thought to this as an UAC issue); this was confirmed by turning off Protected Mode for a test, and the prompt to the user disappeared.…
-
Quick hint: “Server Unavailable” error
I stumbled into this error this afternoon, while working on a repro for a customer: if you need to have your application pool running under an account other than the default NETWORK SERVICE, and when you try to browse your application you get a nasty Service Unavailable error, check if you remembered to add that account to the IIS_WPG group… ? Carlo
-
Compiler Error Message: CS0433 in ASP.NET 2.0
A few days ago a friend of mine had the Compiler Error Message: CS0433 error in his precompiled site, and proposed me a deal: a dinner for my help 😊, and since also Support Engineers sometimes need to eat, I accepted 😉. The exact error message was the following: The type <typename> esists in both <path 1> and <path 2>. Sometimes the error message is quite self explanatory, especially if one of the two assemblies is in BIN and the other is in the GAC (remove the one in the BIN, you don’t need two copies of the same file!), but my friend was getting the following one: Exception information: Exception type: HttpCompileException Exception message: c:\WINNT\Microsoft.NET\Framework\v2.0.50727\Temporary ASP.NET Files\customers\30216428\89bd3cad\App_Web_default.aspx.27046288.rpug8fan.0.cs(112): error CS0433: The type ‘App_Items_63_pgs_default’ exists in both ‘c:\WINNT\Microsoft.NET\Framework\v2.0.50727\Temporary ASP.NET Files\customers\30216428\89bd3cad\assembly\dl3\d1307a39\42cbc228_01a6c701\App_Web_tzn10d4k.DLL’ and ‘c:\WINNT\Microsoft.NET\Framework\v2.0.50727\Temporary ASP.NET Files\customers\30216428\89bd3cad\assembly\dl3\5493a6b9\8880bf21_01a6c701\App_Web_7jlq-fy_.DLL’ Thread information: Thread ID: 1 Thread account name: <server>\ASPNET Is impersonating: False Stack trace: at System.Web.Compilation.AssemblyBuilder.Compile() at System.Web.Compilation.BuildProvidersCompiler.PerformBuild() at System.Web.Compilation.BuildManager.CompileWebFile(VirtualPath virtualPath) at System.Web.Compilation.BuildManager.GetVPathBuildResultInternal(VirtualPath virtualPath, Boolean noBuild, Boolean allowCrossApp, Boolean allowBuildInPrecompile) at System.Web.Compilation.BuildManager.GetVPathBuildResultWithNoAssert(HttpContext context, VirtualPath virtualPath, Boolean noBuild, Boolean allowCrossApp, Boolean allowBuildInPrecompile) at System.Web.Compilation.BuildManager.GetVirtualPathObjectFactory(VirtualPath virtualPath, HttpContext context, Boolean allowCrossApp, Boolean noAssert) at System.Web.Compilation.BuildManager.CreateInstanceFromVirtualPath(VirtualPath virtualPath, Type requiredBaseType, HttpContext context, Boolean allowCrossApp, Boolean noAssert) at System.Web.UI.PageHandlerFactory.GetHandlerHelper(HttpContext context, String requestType, VirtualPath…
-
Broken line in ASP.NET 2.0 TreeView in IE 7
Create a very simple page in ASP.NET 2.0, add a TreeView control and set ShowLines=true; now browse the page with Internet Explorer 7: you’ll very likely see something like this: In IE 6 this looks good… 🤔 The point is that Internet Explorer 7 changes the boxing model: now a box that’s too small to accomodate ita content won’t stretch like it does on all other browsers including IE6, it will try to stay as small as possible. The problem in this case is that the DIV tags generated by the control are just 1 pixel height, which was working fine until now. Here is how the “View source” for the page above looks: 1: [...] 2: <table cellpadding="0" cellspacing="0" style="border-width:0;"> 3: <tr> 4: <td> 5: <div style="width:20px;height:1px"> 6: <img src="/TreeViewSample/WebResource.axd?d=vGK_uMmdWLf5UZMMUhv9tSAl-YQg-jrsZ90xzYAI6TE1&t=632985107273882115" alt="" /> 7: </div> 8: </td> 9: <td> 10: <a id="TreeView1n1" href="javascript:TreeView_ToggleNode(TreeView1_Data,1,TreeView1n1,'l',TreeView1n1Nodes)"> 11: <img src="/TreeViewSample/WebResource.axd?d=vGK_uMmdWLf5UZMMUhv9tfjlKbdZ_ojL4O8CY0ydKO_HFK9lO1t2cZ2AjaDIqJy_0&t=632985107273882115" 12: alt="Collapse New Node" style="border-width:0;" /> 13: </a> 14: </td> 15: <td style="white-space:nowrap;"> 16: <a class="TreeView1_0" href="javascript:__doPostBack('TreeView1','sNew Node\\New Node')" 17: onclick="TreeView_SelectNode(TreeView1_Data, this,'TreeView1t1');" id="TreeView1t1">New Node</a> 18: </td> 19: </tr> 20: [...] As you can see, the first DIV tag contains a style definition with “height:1px”; that’s the problem. And now, here is how we can…
-
The importance of breaking changes
Yesterday I closed a case about a migration issue from ASP.NET 1.1 to 2.0. The customer built this application based on ASP.NET 1.1 to generate some PDF documents on the fly on the web server, and stream the content to the client for reading; the application also served as a sort of archive browser, where online users are able to browse a list of archived PDF files. The customer thought carefully to his error handling (I think he did a very good job), and also decided to customize the standard 404 error page to something more friendly and informative for application’s users, so he configured the <customErrors> section in his web.config to point to a specific page to handle the 404 return codes. But he wanted this custom page to be displayed also if the user requested a non existing PDF file, so he had to add a new mapping in IIS console, to have requests for .pdf files go through the ASP.NET execution channel (aspnet_isapi.dll etc…) and benefit of the advanced features (including security and error handling) granted by the .NET Framework. This worked pretty well fos some time, until the customer decided to migrate his web applications to…