July, 2007

  • Never doubt thy debugger

    Server Error 500, unable to create new session


    I saw this problem reported on a Windows 2000 Server (IIS 5.0), I've not checked if the same could also happen on IIS 6/7...

    The application is build on classic ASP pages and the error appeared about once per day on a test server; when browsing the user got a message reading "unable to create new session" (rough translation from Italian), and when this happens the only solution was to reset IIS (while in that status, even static HTML content was not served).

    Interestingly the Event Log showed quite a few entries like the following:

    Event Type:  Warning
    Event Source: COM+
    Event Category: Activation
    Event ID:    4238
    Date:        03/07/2007
    Time:        11.05.49
    User:        N/A
    Computer:    xxxxxxxx

    COM+ has determined that your machine is running very low on available memory.  In order to ensure proper system behavior, the activation of the component has been refused.  If this problem continues, either install more memory or increase the size of your paging file.  Memory statistics are:
    dwMemoryLoad = 98
    dwTotalPhys = 536358912
    dwAvailPhys = 9453568
    dwTotalPageFile = 1945448448
    dwAvailPageFile = 48668672
    dwTotalVirtual = 2147352576
    dwAvailVirtual = 405975040

    Server Application ID: {3D14228D-FBE1-11D0-995D-00C04FD919C1}
    Server Application Name: IIS Out-Of-Process Pooled Applications

    This turned out to be due to a memory pressure problem in inetinfo.exe: a hang dump showed a problem with the ASP Template Cache  which was using most of the memory (this usually happens when you have a lot of lines of code in one single ASP page, or your application heavily include files); here are some suggestions to mitigate the issue:

    1. Short-term: lower the number of cached ASP pages via the AspScriptFileCacheSize setting in the metabase (mentioned in http://support.microsoft.com/default.aspx?scid=kb;EN-US;914156)
    2. Medium-term: reduce the size of the templates (only include the absolutely necessary "include" files for a given page); also check 25+ ASP Tips to Improve Performance and Style
    3. Long-term: move to ASP.NET since it handles caching of objects more efficiently (if using UserControls versus Includes)

    By the way, point number 1 above resolved the problem for the customer.


    Even if not directly related to this problem, we disabled ScriptScan from McAfee, which is not supported server-side:


    "When installed to a server, McAfee recommends that ScriptScan be disabled. Jscript and VBScript protection is intended for use with Microsoft Internet Explorer and Microsoft Outlook, which generally are not used on server platforms. Additionally, ScriptScan is not designed for high-throughput requirements of servers"


    Quote of the Day:
    Many people take no care of their money till they come nearly to the end of it, and others do just the same with their time.
  • Never doubt thy debugger

    Visual Studio debugger conflicts on port 80


    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 server is running and that incoming HTTP requests are not blocked by a firewall". Another tweak on customers firewall and the problem was fully resolved.



    Quote of the Day:
    He is poor who does not feel content.
    --Japanese proverb
  • Never doubt thy debugger

    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... smile_omg

    The error message clearly refers to an ODBC problem, and a quick research in our internal docs showed that usually this is due to an installation/configuration problem in the involved driver. In this specific case, the customer was using NotesSql 3.02 he downloaded from the IBM site.

    We decided to use Filemon and Regmon to get an idea of what was happening at file system and registry level and compare the two situations (working and not working); after some digging into the logs, we found that when the application was working fine it was looking (and loading) for notes.ini under the user's folder profile (c:\documents and settings\account\...), while in the failing situation we saw some king of probing but the application was not able to find the file... We decided to move the notes.ini from it's location to the Notes driver's installation folder, and that did the trick! smile_nerd.



    Quote of the Day:
    At the working man's house hunger looks in but dares not enter.
    --Benjamin Franklin

  • Never doubt thy debugger

    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! smile_whatchutalkingabout  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 for the application pool.

    To kill two birds with one stone, I opened WFETCH to understand what was going wrong.

    First fact: if you are running with a local account, you'll use NTLM and not Kerberos, and NTLM was working fine.

    Second fact: using WFETCH to access the same URL (with the app pool running as domain account) returned 0x80090322 (The target principal name is incorrect.): “Unable to InitializeSecurityContext”

    The error means that the account used to run the process does not have permission to log-in as a service; in my repro I found a domain policy was setting that value, and the customer told me they had the same. So, to resolve the problem I run the following command:

    cscript C:\inetpub\AdminScripts\adsutil.vbs set w3svc/NtAuthenticationProviders "NTLM"
    (you may also want to have a look at this KB)

    Note that this will prevent you from using delegation (which is possible only using Kerberos), but the customer didn't need it so he was happy with this solution and the story stopped here...



    Quote of the Day:
    When you get to the end of your rope, tie a knot and hang on.
    --Franklin D. Roosevelt
  • Never doubt thy debugger

    Google uses .NET...?!?


    Have a look at this link: https://survey.google.com/wix/p0986235.aspx

    google's survey

    Uhm... let's have a look at the source HTML of the page, and we'll not find the "_VIEWSTATE" hidden field (it should be there also if we disable the viewstate in the @Page directly and for every control in the page) and the "__DoPostBack" Javascript method to submit the form... smile_thinking

    I may be completely wrong, they could have removed the unused _viewstate hidden field on the server right before sending the html stream to the client, but why? Just to save 2-3 Kb?

    Don't know... sounds like a "trick"... maybe they just wanted to check the reaction about the file extension... smile_wink 

    Just to be clear: I don't find anything wrong with it, just fun smile_teeth

    What do you think?



  • Never doubt thy debugger

    Channel9 speaks Italian


    A few weeks after the Italian MS bloggers have joint in a (for the moment) small community and started promote their content, today I've been told that Channel9 started hosting non-English content, and guess what...? The first video of this series (in the home page smile_omg) is in Italian! smile_teeth

    They'll interview Italian people working in Redmond, of course talking about technology; in this first video Vittorio Bertocci interviews Mauro Ottaviani and they talk about WCF and performance. So, if you can read Italian keep an eye on http://channel9.msdn.com/tags/Italia smile_wink



  • Never doubt thy debugger

    Blog addict?


    Uhm... should I try to improve or somehow "worsen" this figure? smile_omgsmile_shades

    blog addiction


Page 1 of 1 (7 items)