softlogger Latest Articles ::Web-Design

aspnet_wp.exe can not be started. Code: 80070003

A developers strayings — 2008-02-19T00:00:00

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 -server tcp:port=8090.exe PATH NOT FOUND
inetinfo.exe:1112 OPEN C:\Debuggers\cdb.exe -server tcp:port=8090 PATH NOT FOUND

As you may know, cdb.exe usually ships with the Debugging Tools for Windows, and C:\Debuggers is a folder we usually use (at least in CSS) to install the debugger... This made me think to a problem I had a while ago with my notepad (see here), so I asked the customer to check if he had a this registry key:

hklm\software\microsoft\windows nt\currentversion\image file execution options\aspnet_wp.exe

This is usually created by gflags, and those Path not found errors means the customer actually had the Debugging Tools for Windows installed in C:\Debuggers and then for some reason someone moved (or deleted) the folder without first removing the gflags entry from the registry: if cdb.exe cannot be found, then the target process (in this case aspnet_wp.exe) cannot be started.

We just deleted the registry key and the site was back online.

Carlo

Quote of the Day:
Sharing money is what gives it its value. -- Elvis Presley, singer

HTML Design Principles

Nicholas Allens Indigo Blog — 2007-11-29T00:00:00

Earlier this week the W3C HTML working group published a list of design principles for working on HTML 5. HTML isn't strictly relevant for a web services programmer but I figured that there was sufficient overlap that many people would find this work interesting. Here's the list of principles, although you'll have to follow the earlier link if you want additional descriptions.

Support Existing Content
Degrade Gracefully
Do not Reinvent the Wheel
Pave the Cowpaths
Evolution Not Revolution
Solve Real Problems
Priority of Constituencies
Secure By Design
Separation of Concerns
DOM Consistency
Well-defined Behavior
Avoid Needless Complexity
Handle Errors
Media Independence
Support World Languages
Accessibility

Although not the intention, most of these principles turn out to apply equally well for the world of web services. DOM Consistency, Media Independence, and Accessibility don't map so well because most services take the separation between content and presentation to a logical extreme and essentially only deal with content. It's not that these problems don't exist in applications anymore but that the cause and solution have been punted to other parts of the system. Paving the Cowpaths comes up less frequently because usage errors tend to be scrutinized and rejected rather than tolerated, preventing alternative, illegal formulations from becoming widespread.

ListView and DataPager in ASP.NET 3.5 Search Engine Optimization ( SEO ) Friendly

David Hayden - Florida .NET Developer - C# and SQL Server — 2007-11-23T00:00:00

There are new ListView and DataPager controls in ASP.NET 3.5 that help you clean up the HTML rendered in your pages as well as offer paging that are search engine optimization ( SEO ) friendly. You will find a lot of blog posts and articles on the web saying just the opposite, but many of these posts on the ListView and the DataPager were written during Visual Studio 2008 Beta.

JavaScript Behavior Tutorial

Aspects of AJAX — 2007-11-20T00:00:00

The complete Tutorial is now online.

If you worry about too much JavaScript fragments in too many places you need a concept of reusing client side functionality on a component level.

This is a step by step instruction for building a new client side component by using the JavaScript behavior mechanism. It is first implemented without using any server side help by only implementing JavaScript in a plain html file. Later it is evolved into an ASP.NET user control.

See how to implement JavaScript behaviors from the scratch.

http://www.mathertel.de/AJAXEngine/S05_JSB/default.aspx

New release of the framework and samples

The zip files with the complete framework and samples have also been updated today:

Ajax.zip (1.367 kByte) This Zip-File contains the ASP.NET 2.0 web project that builds this side. The complete AJAX Engine and all samples are included. Use this project when you want to start building your AJAX web application.

AJAXEngine.zip (159 kByte) This Zip-File contains the core files of the AJAX engine and the AJAX controls. You can use this if you want to update your project with the updated core files.

How To Handle The DIV Tag Around ASP.NET Hidden Inputs

youve been HAACKED — 2007-06-16T00:00:00

One praiseworthy aspect of ASP.NET 2.0 is its much improved XHTML compliance. However, there is one particular implementation detail related to this that causes some web designs to break and could have been implemented in a better manner.

The detail is how ASP.NET 2.0 will wrap a DIV tag around hidden input fields. My complaint isn’t that Microsoft added this DIV wrapper, because it is needed for strict compliance. My complaint is that there is no CSS class or id on the DIV to make it easy to exclude CSS styling on it.

For example, here is a snippet from the output of a simple page.

<form name="form1" method="post" action="Default.aspx" id="form1">
<div>
<input type="hidden" name="__VIEWSTATE" id="__VIEWSTATE" value="Omitted" />
</div>

<div>
Hello World
</div>
</form>

It would have been nice if the author of this code could have simply added something like:

<div class="aspnet-generated">
<input type="hidden" name="__VIEWSTATE" id="__VIEWSTATE" value="Omitted" />
</div>

It is quite common for web designers to apply a specific style to all DIVs on a page, for example, adding a padding of 5px.

<style type="text/css">
  div {padding: 5px;}
</style>

Unfortunately, this leaves a gap where the ASP.NET generated DIV is located.

In a comment made on his blog, Scott Guthrie makes this remark on this topic:

You could modify your CSS to exclude the <div> we create by default immediately underneath the form tag.
In general I’d probably recommend having as broad a CSS rule as the one you have above - since it will effect lots of content on the page. Can you instead have it apply to a CSS class only?

Yes, you could modify the CSS to exclude the first child DIV of the FORM tag by using a child selector and a first-child pseudo class like so:

<style type="text/css">
  div {padding: 5px;}
  form>div:first-child {padding: 0; margin: 0;}        
</style>

Unfortunately, IE 6 doesn’t support child selectors nor first-child pseudo classes. Since IE 6 is still quite widely used, this is not a viable solution.

Regarding Scott’s second question, this isn’t always reasonable because many web designs apply certain styles most DIVs on a page and then exclude a few that shouldn’t have that style. In that situation, it takes more work to give every DIV a CSS class so you can apply the style to just that class. It is simpler to use an exclusionary approach in these cases. Simply apply the style to all DIVs and exclude the ones that need to be excluded.

Unfortunately, because of the way this DIV wrapper was implemented and, because of CSS non-compliance in IE 6, it’s not possible to exclude this DIV using CSS alone. It requires changing the markup.

Fortunately, there’s an easy solution with a slight change to your markup, but it requires changing your markup just a bit. Just wrap your content in a DIV with a specific ID.

<form id="form1" runat="server">
  <div id="main">
    <div>
      Hello World
    </div>
  </div>
</form>

And then style it like so.

<style type="text/css">
  div {padding: 0; margin: 0;} /* generated div */
  #main div {padding: 5px;} /* all other divs */
</style>

This is a lot easier (and higher performing) than trying to muck around with the output via the HttpResponse.Filter.

So while the solution is easy, it still bothers me that it is necessary. One main reason why is that I often get CSS designs handed to me and I have to go through and make sure to make this change appropriately. I’d rather just be able to plop a one line CSS change into every stylesheet like so:

div.aspnet-generated {padding: 0; margin: 0;}

On another note, one other interesting side-effect of this change in ASP.NET 2.0 is that many implementations for moving viewstate to the bottom of the page end up breaking XHTML compliance because they only move the input tags and not the entire DIV to the bottom.

Technorati tags: ASP.NET, CSS, DIV

JavaScript Includes - Be Careful With Your Syntax!!

Scott on Writing — 2007-04-18T00:00:00

When adding client-side script to a web page, the JavaScript can be embedded directly within the page's HTML or provided via an external reference similar to include files in programming languages. When using JavaScript include files, the browser will cache the file so that it doesn't need to be downloaded on subsequent postbacks and page visits. By embedding the script directly wthin the page's markup, the script must be downloaded on each page visit (with the rest of the markup), which is wasteful if the script content is static. Therefore, JavaScript include files lessen the amount of data the client must download, improving the end user's experience. So JavaScript includes are a Good Thing. In fact, when using certain ASP.NET Web controls (like validation controls, the Menu, and so on), script includes are used to inject the necessary client-side plumbing).

JavaScript includes have a simple enough syntax:

Of course, XML rules allow for elements with no inner content to use “/>” as a shortcut rather than needing the closing tag. In a recent project I assumed this would work for JavaScript includes and added a number of includes using syntax like:

Well, guess what? That doesn't work, at least not in Internet Explorer. IE ignores the JavaScript include altogether, not sucking in any of the JavaScript content from pathToJavaScriptFile. If your JavaScript file contains only infrequently-used functions, you of course don't find this out until you perform some action that calls one of these functions in pathToJavaScriptFile and you end up getting a script error. And then, of course, you spend the next hour pouring over the JavaScript code and the page's rendered markup to find what's wrong, not realizing that the browser hadn't sucked down the JavaScript include file because you used “/>” instead of “</script>”.

What's particularly odd is that if you use a tool like Fiddler to inspect the HTTP traffic, the browser still makes a request to pathToJavaScriptFile! It just doesn't 'execute' the script or 'register' the functions if you end the <script> reference with “/>“ instead of “</script>“. Ditto if you fail to end the <SCRIPT> element (that is, if you have <script src="pathToJavaScriptFile">).

Long story short - make sure you don't make the same mistake I did. Save yourself an hour of frustration by adding the verbose “</script>” when externally referencing a JavaScript file instead of trying to save six bytes by omitting it.

SYSK 310: The Difference Between setInterval and setTimeout

AppDev: Something You Should Know by Irena Kennedy — 2007-03-20T00:00:00

In JavaScript, you have two options to execute a specific function in the future, i.e. after a specified time interval:

window.setInterval and window.setTimeout

Both functions have similar signatures, e.g.:

var timeout = window.setTimeout("javascript statement", milliseconds)

var intervalId = window.setInterval("code", milliseconds[, "lang"])

As you can see, the first difference is that the setInterval function supports running client-side script in languages other than JavaScript. However, there is a bigger difference between the two, not discernable by syntax: the setTimeout method is completed after the function is invoked, whereas the setInterval will continue calling the specified function until clearInterval() is called or the window is closed.

In other words, the following two code snippets result in same outcome:

var t = setTimeout("refresh()", 5000);

function refresh()

{

. . .

var t = setTimeout("refresh()", 5000);

}

vs.

var i = setInterval("refresh()", 5000);

function refresh()

{

. . .

}

Note: to cancel the setTimeout method, call clearTimeout.

Summary:

So, it appears clear – use setTimeout when you need to trigger a delayed function invocation once, use setInterval for multiple (timer-like) calls…

There is one exception: if you need to change the parameter values passed into the function, and the data values are set (changed) during the current execution cycle, reconsider the use of setTimeout – it may remove the need for global variables, and, perhaps, be a better choice…

Crashing IE 6 with style(sheets)

deferred until inspiration hits — 2007-02-15T00:00:00

Over about the last day and a half, if you used Internet Explorer 6 to browse any of the reviews on reevoo.com, then we should apologise. It seems that, apart from breaking the layout somewhat, we’d actually managed to cause IE 6 to crash. Not cool. A concerted effort this morning got the problem sorted, but it took longer than it should’ve done, especially when you consider that about 75% of our traffic is from users of IE 6…

Anyway, with the embarrassment out of the way, I thought I’d share the remotely interesting¹ findings of the investigation into the browser crash. It turns out that a combination of these three little lines of css, and any doctype declaration², will cause IE 6 to hang while waiting for the magic Windows kiss of life.

margin-left: 240px;
margin-right: 10%;
width: expression(document.body.offsetWidth - 256);

It is not the specific values (240px, 10% and 256) in the lines above that are of interest – I was able to express and suppress the problem by altering those. Unfortunately, I didn’t spend any time trying to find the threshold of the problem, and am therefore unsure as to the reason for this behaviour.

The offending, nasty, IE hack has now been removed. In addition, the day has been spent working with the designer monkey (ahh, you can call him Adam if you like) to start tidying up the, still somewhat cumbersome, stylesheets.

For the curious, the simplest html page I could come up with that exhibits the crash behaviour in IE 6 is below.

<!-- <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd"> -->
<!-- <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd"> -->
<!-- <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> -->
<!-- <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> -->
<!-- ANY OF THE ABOVE DOCTYPES CAUSE THE PROBLEM.  NO DOCTYPE = NO PROBLEM -->
<html>
  <head>
    <style type="text/css">
      #content {
        margin-left: 240px;
        margin-right: 10%;
        width: expression(document.body.offsetWidth - 256);
      }
    </style>
    <title>testing ie6</title>
  </head>
  <body>
    <div id="content">blurgh</div>
  </body>
</html>

[1] They’re really not interesting.

[2] If there is no doctype declaration, the browser doesn’t crash (something to do with standards mode I believe).

Setting Alignment in TextBoxes...No Looking Glass Required

blue collar — 2007-02-07T00:00:00

In yesterday's post I stated that "non-character keys do not trigger KeyPress events." While that is perfectly true, I misunderstood what was meant by a non-character key. In the non-managed Win32 world, pressing a key generates a WM_KEYDOWN, one or more WM_CHAR messages, and a WM_KEYUP message. The managed KeyPress event corresponds to the WM_CHAR message. Windows generates WM_CHAR messages for keys that are mapped to ASCII characters by the keyboard driver. Since pressing the Enter key generates an ASCII character code (0xA, 0xD, or both), a KeyPress event is generated for it.

So, while the code I posted yesterday works, it can be simplified by eating the Enter key in the textbox's KeyPress event handler rather than using the form's KeyPreview.


        private void textBox1_KeyPress(object sender, KeyPressEventArgs e)
        {
            if ('\r' == e.KeyChar)
            {
                // Supress enter key
                e.Handled = true;
            }
        }

In addition, since the textbox is no longer dependent on the form for functionality, I can package it up in it's own class.


    public class TextBoxWithAlignment : TextBox
    {
        // Remember whether user wants the textbox to act like a 
        // single-line or multiline textbox.
        //
        private bool multiline = false;

        public TextBoxWithAlignment()
        {
            // The underlying control will always be a multiline textbox
            //
            base.Multiline = true;
        }

        protected override void OnKeyPress(KeyPressEventArgs e)
        {
            // When the user wants a single-line textbox,
            // eat carriage returns
            //
            if (!this.multiline && '\r' == e.KeyChar)
            {
                e.Handled = true;
            }
            base.OnKeyPress(e);
        }

        // Override the Multiline property to use the internal multiline flag
        //
        public override bool Multiline
        {
            get
            {
                return this.multiline;
            }
            set
            {
                this.multiline = value;
            }
        }
    }

Pretty nifty, IMHO.

Cheers
Dan