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…
-
LogParser scripts for various occasions…
I’ve been working again with LogParser lately to extract some statistics for an IIS server which was facing a suspicious activity from the outside world: they were getting literally thousands of requests from a bunch if IP addresses to their page to request a “forgot password” for their online services. For this post is not important how we resolved the problem, but rather that of the occasion I had to create a few LogParser scripts to extract some statistics from the IIS logs, so I through those might be useful for other people too… Of course you’re free to change them to adapt to your needs. Before you proceed, a couple of words on the scripts: those are meant to be “generic” and run with a batch file which accepts some input arguments, but you can run them from a command prompt directly replacing the “%x” placeholders; also, I print them on multiple lines to be easier to read, but you must run then on a single line. This is to count how many requests you got to a specific page with a specific value in the query string (we were extracting data for the “change password” page with a…
-
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…
-
Application, Page and Control lifecycle
The problem Every now and then we receive an advisory case from a customer whom needs some advices from us about how to implement some kind of functionality, and this particular one had an interesting and weird behavior with the viewstate in a custom composite control: basically the customer implemented a sort of tabbed control which had to act as a container for other controls like checkboxes, and was meant to be used at design time within Visual Studio by other developers. The control itself was actually based on a CompositeControl and a View (and MultiView) class, and everything was apparently working fine until he tried to uncheck one of the checkboxes within the control and submit the page: after the postback the checkbox was still flagged ?. The custom control was clearly the the one having the problem because another checkbox outsite it (just placed somewhere else on the page) worked as expected. It’s interesting to note that the customer has customized the viewstate management and was overriding the SaveViewState and LoadViewState events, and on my experience viewstate and the chain of events which occurs in the page lifecycle are often the ones to blame for such problems… A…
-
Don’t let IE local cache drive you crazy!
I stumbled across this issue multiple times during my life of web developer (which begun about 10 years ago), it appeared every now and then to complicate things when I was in the middle of a heavy debugging sessions and doing frequent changes to my pages; I was expecting some kind of results but despite the fact that the code was looking good, there were no signs of those changes. Sometimes even adding a new UI element like a button or an image or changing the color of a header had no effect… ? Having a look at the page source within IE demonstrated the browser was somehow right not showing the new image or color because it was not there in the code… where was that source coming from? ? Well, if it does not come from the web server, then it’s loaded from the IE local cache… so let’s go to Internet Options > General > Delete > Temporary Internet Files, give it another try and guess what? This time it works…! So, not sure why, but for some reason IE was not refreshing its case and was using an outdated version of my pages. Then after a…
-
The weight of security
This morning I had a call with a customer which reported a performance problem opening and compiling a VB.NET 2005 web application made of hundreds of files; we have a couple of hotfixes for VS2005 included in SP1, but the customer already had it. He reported a delay in term of dozens of seconds to load, save, compile (doing anything) on the remote project, while opening it on localhost worked like a charm (so it was hard to think that Visual Studio was at fault here…); also copying a big file (120 Mb) from the server to the client just took the time of a click (the network is then working fine)… ? To make the story short, I asked him to tell me step by step how he was opening the project: File > Open > Remote Site > http://ipaddress/application. Using the IP address here means the project will be recognized as Internet Zone (IE security) and additional security checks and restrictions will be applied. I asked the customer to enter the server name instead of the IP address and everything was fully loaded at the speed of light! To be honest I didn’t though that this could have…
-
Corrupt installation? Do not repair Visual Studio
(Unable to start debugging on the web server. An error occurred that usually indicates a corrupt installation. If the problem persists, repair Visual Studio installation via ‘Add or Remove Programs’ in Control Panel) I saw this happening on a Vista x64 while trying to debug an ASP.NET application and needless to say (☹️), repairing Visual Studio does not help. This is a misleading error message which might appear when you try to debug an ASP.NET application on a 64 bit OS and you configured your application pool to run a 32 bit worker process; I know it will be changed to a more meaningful message, but I’m not sure about the timeframe (I can’t repro so I’m not able to check how Visual Studio 2008 behaves). What to do then? Check the advanced settings for your application pool and set “Enable 32-bit applications” to “False” By the way, I was this error in conjunction with this one so pay attention if you’re hitting one of the two… Carlo Quote of the Day: Sincerity is the highest compliment you can pay. –Ralph Waldo Emerson