Let’s say you developed an ASP.NET application the assemblies are hosted on a network share: if you try to get the authenticated user using System.Environment.UserName you’ll get the account configured to access the network share in IIS (Connect As User). Side note: you’re also using Integrated Authentication and impersonate=”true” in web.config. Why? Well… ASP.NET impersonates the “Connect As” user you specify in IIS console, therefore Context.Identity.Name returns that account. If you need the authenticated user you must rely on the “old” Request.ServerVariables[“LOGON_USER”] as you were used to do in classic ASP. Carlo Quote of the day: It is no good to try to stop knowledge from going forward. Ignorance is never better than knowledge. – Enrico Fermi
-
-
Very slow TreeView in UpdatePanel
This is what we got couple of weeks ago: an Ajax enabled ASP.NET web application was using a TreeView control within an UpdatePanel to show a complex tree of hierarchical data (the sample we got had more than 2.000 nodes with varying degrees of nesting). The result was that browsing the tree within IE was considerably slower if compared with Firefox, about 4 times (where Firefox took 2 seconds to complete the operation, IE took 8 seconds a and sometimes a bit more). With a repro in our hands, a network trace demonstrated that the communication between client and server was working fine (the problem reproduced also on localhost); while having the problem IE was burning a lot of CPU and the relevant thread had a callstack link this: kernel32!TlsGetValue+0xb jscript!GcContext::GetGc+0xc jscript!NameTbl::FBaseThread+0xb jscript!NameTbl::GetVal+0xe jscript!VAR::InvokeByName+0x10d jscript!VAR::InvokeDispName+0x43 jscript!VAR::InvokeByDispID+0xb9 jscript!CScriptRuntime::Run+0x167f jscript!ScrFncObj::Call+0x8d jscript!NameTbl::InvokeInternal+0x40 jscript!VAR::InvokeByDispID+0xfd jscript!VAR::InvokeByName+0x165 jscript!VAR::InvokeDispName+0x43 jscript!VAR::InvokeByDispID+0xb9 jscript!CScriptRuntime::Run+0x167f jscript!ScrFncObj::Call+0x8d jscript!NameTbl::InvokeInternal+0x40 jscript!VAR::InvokeByDispID+0xfd jscript!VAR::InvokeByName+0x165 jscript!VAR::InvokeDispName+0x43 jscript!VAR::InvokeByDispID+0xb9 jscript!CScriptRuntime::Run+0x167f jscript!ScrFncObj::Call+0x8d [...] mshtml!CBase::InvokeEvent+0x1ad mshtml!CBase::FireEvent+0x105 mshtml!CXMLHttpRequest::Fire_onreadystatechange+0x5b mshtml!CXMLHttpRequest::CReadyStateSink::Invoke+0x1d [...] The code behind that was quite simple: protected void onSelectNodeChange(object sender, EventArgs e) { Session["selectedNode"] = TreeView1.SelectedNode.ValuePath; Session["idFirstTree"] = TreeView1.SelectedNode.Value; UpdatePanel2.Update(); } The problem is that the hole tree is destroyed and recreated at every iteration (Sys$WebForms$PageRequestManager$_destroyTree in MicrosoftAjaxWebForms.js); the method traverses…
-
MaxConnection does not have effect on ASP.NET 2.0
An interesting change which you might have missed in .NET 2.0 is about the autoConfig setting for the <processModel> element. The customer was running out of available connections while accessing a remote web service and was trying to apply what’s suggested in Contention, poor performance, and deadlocks when you make Web service requests from ASP.NET applications but apparently the change had not effect: a memory dump shown still 12 available connections even if he set MaxConnection=96. Interesting to note that reverting the application to .NET 1.1 the problem disappeared. The different behavior is determined by the autoConfig value, which affects only ASP.NET applications and not Console, WinForm etc… (while the <processModel> threading configuration in .NET 1.x affected all .NET apps running on the machine): Specifies whether to automatically configure the following settings to achieve optimal performance based on the machine configuration:The maxWorkerThreads attributeThe maxIoThreads attributeThe minFreeThreads attribute of the httpRuntime element.The minLocalRequestFreeThreads attribute of the httpRuntime elementThe maxConnection attribute of the <connectionManagement> Element (Network Settings) element. The values are set according to the KB article at http://support.microsoft.com/?id=821268. This attribute does not affect the .NET Framework client applications; only ASP.NET applications. The autoConfig attribute can be one of the following values. True: Indicates that ASP.NET automatically configures…
-
Web Garden, AppDomain, statics… when Sql Server is not enough to save your session
Things have gone a bit crazy lately, we’ve been under a huge workload and the time left for blogging was virtually non existent… but the good thing is that I’ve been working on a few interesting cases I hope I’ll have time to blog about, and this is the first one. The problem The application was running on a Windows 2003 cluster and the well known solution to avoid session problems in a multi server environment is to store user sessions out-of-process, either using a State Server or Sql Server, and in this case we were using Sql Server; this is also the right approach if you are using Web Garden for your application pool and this is the situation we were in (web garden + state on Sql Server). But some session-wide arrays the customer was using were suddenly empty as soon as the customer increased the number of worker processes above 1 for the application pool, which is exactly what is not supposed to happen with <sessionState mode=”SqlServer” … />. At the beginning I thought to a configuration problem on the affected servers but the usual quick check on the metabase shown that was not the case, so…
-
Unable to use SQL Server because ASP.NET version 2.0 Session State is not installed on the SQL server
I run across this error today while setting up a repro for a problem I’m working on; the first time I through I did something wrong between the mess of things which case across my hands today (maybe I’ve used the wrong .sql script? ?), but after removing the database from Sql Server and re-running correct InstallSqlState.sql, I got the same message once again ?. Ok then, time for a (hopefully) quick research on this error and finally I found out a few things which might cause it. Running both ASP.NET and classic ASP in the same application pool? If the application pool is also running classic ASP pages, and those classic ASP pages use .NET 2.0 components, and those classic ASP pages which use .NET components are called before any ASP.NET 1.1 page, then we’ll load CLR 2.0 (first come, first serve ?) and of course it will look for his specific ASPState version. Ok, there are a lot of “if” in this case, but it’s still a possibility… not my scenario, through. Where are your session tables? If you use aspnet_regsql wizard, session tables are not added by default so you need to run the following command: aspnet_regsql.exe…
-
aspnet_wp.exe can not be started. Code: 80070003
This was a Windows 2000 server with ASP.NET 1.1 installed, and for some reason the customer was unable to start his web applications, he was getting "Server Application Unavailable" messages on the client. We found the Application event log full of entries like this one: Event Type: Error Event Source: ASP.NET 1.1.4322.0 Event Category: None Event ID: 1084 Date: 18/02/2008 Time: 15.59.43 User: N/A Computer: <computername> Description: aspnet_wp.exe could not be started. The error code for the failure is 80070003. This error can be caused when the worker process account has insufficient rights to read the .NET Framework files. Please ensure that the .NET Framework is correctly installed and that the ACLs on the installation directory allow access to the configured account. The next logical step is to use Process Monitor to try to spot any "Access denied" errors, but there weren’t. Interestingly within the procmon trace we instead found quite a few entries similar to the following inetinfo.exe:1112 OPEN C:\Debuggers\cdb.exe PATH NOT FOUND inetinfo.exe:1112 QUERY INFORMATION C:\Debuggers\cdb.exe -server PATH NOT FOUND inetinfo.exe:1112 QUERY INFORMATION C:\Debuggers\cdb.exe -server.exe PATH NOT FOUND inetinfo.exe:1112 OPEN C:\Debuggers\cdb.exe -server PATH NOT FOUND inetinfo.exe:1112 QUERY INFORMATION C:\Debuggers\cdb.exe -server tcp:port=8090 PATH NOT FOUND inetinfo.exe:1112 QUERY INFORMATION C:\Debuggers\cdb.exe…
-
Want to persist your properties as markup?
Last week I got a request from a customer whom was developing a custom ASP.NET control targeted for other developers, and one of his requirements was to persist the control’s properties in the html markup, even for the default values which normally Visual Studio removes: since those are default values the assumption is that we don’t need to persist them in the markup (what usually happens is that if you change the value of a property through the property grid this is reflected in the html markup, but if you later set the value back to its default the designer removes the corresponding markup since it’s no longer needed), but the requirement here was to persist them anyway. To be honest I had never thought to this possibility (who knows, maybe I’m too used to do things in the Microsoft way ?) and despite my researches I’ve not been able to find this answer anywhere in our internal docs and samples, so we started working on a sample together (well, me from my office in Milan and the customer in his office in Crecchio, central Italy) and we also involved an Escalation Engineer (Radomir Zaric, thanks for your help!) to…
-
The message received from the server could not be parsed
Again on the Ajax-compression subject (see here and here), here’s another error I got recently: Sys.WebForms.PageRequestManagerParserErrorException: The message received from the server could not be parsed. Common causes for this error are when the response is modified by calls to Response.Write(), response filters, HttpModules, or server trace is enabled. The customer was using the GZipStream class within an HttpModule to compress the ASP.NET output; everything was working except in pages where he was using some UpdatePanel controls, where he was getting error messages like the above. As you can guess if you’ve read my previous posts, with http compression the response stream was being truncated. There are a couple of solutions available to this error: do not use the HttpModule and rely on IIS compression, or move the application to the .NET Framework 3.5. Remove the HttpModule from web.config Assure ScriptResource is not compressed: <scriptResourceHandler enableCompression=”false” enableCaching=”true” /> Open the IIS Manager Right click on “Web Sites” folder > Properties Click the “Services” tab Check “Compress application files” and “Compress static files” Apply and confirm all dialogs Stop IIS Open a command prompt and go to C:\Inetpub\AdminScripts Run the following commands to add .js, .aspx and .axd to the compression…
-
Need to print from a x64 machine? Can you wait 60 seconds?
I guess some of you might have developed a web application which, among other functionalities, prints some kind of report; and sooner or later you might consider to move the application to a 64 bit machine. At this is what this customer did. They had this ASP.NET application which allows the user to run some queries on a backend database and then print the result on a network printer connected to the web server; under some circumstances the application was hanging for 60 seconds (always 60 seconds) before timing out; of course everything was running fine on a 32 bit machine (i.e. we never managed to reproduce the issue there). At the beginning we thought to some kind of network timeout on the customer’s network or a configuration problem on the server (the application is quite complex so was not possible to have a repro to run and debug on my machine), and this was partially confirmed by a hang dump which showed some error messages about the printer, but this was not consistent enough to get a clue. What was consistent was the use of winspool.dll ntdll!NtDelayExecution(void)+0x15 kernel32!SleepEx(unsigned long dwMilliseconds = 0x3e8, int bAlertable = 0)+0x68 kernel32!Sleep(unsigned long dwMilliseconds…
-
Ajax resource intermittently not accessible (http compression)
A few days before Christmas I had a case where the customer was intermittently getting troubles with his javascript/Ajax resource; as usual everything was working fine on the development machine, but when moved on the production server the application started throwing some client side javascript exceptions like “myVar is undefined” which means that the Ajax resource was not accessible by the browser. After some of the usual checks and discussions with the customer we found out that the production server was using HTTP Compression which is an old friend of mine (I already rambled about it here); they developed a custom HTTP Module to implement the .NET Framework compression classes and mechanism and disabling it was not an option, since their resource were quite large were affecting the applications’ performance. Then I had a couple of weeks off for Christmas and my colleague Gunnar took over the case (isn’t nice when you go on holiday and someone else takes care of the job for you? ?) and with some further debugging they found this interesting method: private static bool IsCompressionEnabled(HttpContext context) { return ScriptingScriptResourceHandlerSection.ApplicationSettings.EnableCompression && ((context == null) || !context.Request.Browser.IsBrowser("IE") || (context.Request.Browser.MajorVersion > 6)); } This means that Ajax does…