August 2007 Blog Posts
Catastrophic Failure (Exception from HRESULT: 0x8000FFFF (E_UNEXPECTED))

I came across the following IIS/ASP.NET while working on our production servers for


Server Error in '/' Application.

Catastrophic failure (Exception from HRESULT: 0x8000FFFF (E_UNEXPECTED))

Description: An unhandled exception occurred during the execution of the current web request. Please review the stack trace for more information about the error and where it originated in the code.

Exception Details: System.Runtime.InteropServices.COMException: Catastrophic failure (Exception from HRESULT: 0x8000FFFF (E_UNEXPECTED))

Source Error:

An unhandled exception was generated during the execution of the current web request. Information regarding the origin and location of the exception can be identified using the exception stack trace below.

Stack Trace:


[COMException (0x8000ffff): Catastrophic failure (Exception from HRESULT: 0x8000FFFF (E_UNEXPECTED))]


[FileLoadException: Could not load file or assembly 'Microsoft.JScript, Version=, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. Catastrophic failure (Exception from HRESULT: 0x8000FFFF (E_UNEXPECTED))]

System.RuntimeTypeHandle._GetTypeByName(String name, Boolean throwOnError, Boolean ignoreCase, Boolean reflectionOnly, StackCrawlMark& stackMark, Boolean loadTypeFromPartialName) +0

System.RuntimeTypeHandle.GetTypeByName(String name, Boolean throwOnError, Boolean ignoreCase, Boolean reflectionOnly, StackCrawlMark& stackMark) +72

System.RuntimeType.PrivateGetType(String typeName, Boolean throwOnError, Boolean ignoreCase, Boolean reflectionOnly, StackCrawlMark& stackMark) +58

System.Type.GetType(String typeName) +48

System.CodeDom.Compiler.CompilerInfo.get_IsCodeDomProviderTypeValid() +9

System.Web.Compilation.CompilationUtil.GetRecompilationHash(CompilationSection ps) +1800

System.Web.Configuration.CompilationSection.get_RecompilationHash() +68

System.Web.Compilation.BuildManager.CheckTopLevelFilesUpToDate2(StandardDiskBuildResultCache diskCache) +741

System.Web.Compilation.BuildManager.CheckTopLevelFilesUpToDate(StandardDiskBuildResultCache diskCache) +46

System.Web.Compilation.BuildManager.PrecompiledAppRuntimeModeInitialize() +709

System.Web.Compilation.BuildManager.Initialize() +3581889

System.Web.Compilation.BuildManager.InitializeBuildManager() +228

System.Web.HttpRuntime.HostingInit(HostingEnvironmentFlags hostingFlags) +333


[HttpException (0x80004005): Could not load file or assembly 'Microsoft.JScript, Version=, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. Catastrophic failure (Exception from HRESULT: 0x8000FFFF (E_UNEXPECTED))]

System.Web.HttpRuntime.FirstRequestInit(HttpContext context) +3540923

System.Web.HttpRuntime.EnsureFirstRequestInit(HttpContext context) +69

System.Web.HttpRuntime.ProcessRequestInternal(HttpWorkerRequest wr) +275


Version Information: Microsoft .NET Framework Version:2.0.50727.832; ASP.NET Version:2.0.50727.832


The issue only appeared when ASP.NET was initializing on the first request from a web browser. If you requested the website a second time, the application would finally kick-in and start. However, if you restarted the W3SVC service (effectively reloading IIS and ASP.NET), and request the site again, you'll get the error. In a production environment, whenever you restart the W3SVC service, you don't want errors like this popping up.

I looked in C:\WINDOWS\assembly, and Microsoft.Jscript was in the GAC. I figured this might be a permission issue with the IIS worker process identity that ASP.NET uses. We currently host our web-app over a network share, and have a separate identity access the network share. So, I setup the worker process application pool identity to use a configurable identity instead of the predefined Network Service account.

Now, the problem seemed to have gone away. I guess it's one of those annoying mysterious windows flukes :) Oh, and don't forget to use:

aspnet_regiis.exe –ga UserAccount

To grant access to the IIS Metabase and permissions to the UserAccount running the worker process, otherwise, you'll get "Service Unavailable" errors.

Hope that helps.


Here's some more information that might be helpful:

The Strategy Design Pattern

Today, I'm going to write about the strategy design pattern and give some examples on where it should be used and why it's useful. I'm really sleepy, only had 3 hours of sleep, so I hope I can do this quick and off the top of my head.


The Problem and Design Smell

Suppose we have the following class hierarchy:

We have an abstract Animal class, that has two virtual methods Eat() and MakeNoise(). Both household Cat and household Dog classes inherit from Animal, along with inheriting behavior animal behavior. Inheriting behavior typically leads to bad design and maintainability. Let's look at the code implementing the classes:

When we run these classes, we get the following output:

The problem ('design smell') associated with this approach is simply the way we are placing the implementation of the actions Eat() and MakeNoise() inside the concrete classes. This doesn't exactly lead to a maintainable design. For example, suppose we want to extend our animal kingdom by introducing an AllyCat class. An AllyCat might have different implementations of Eat() (eating out of the trash), but still have the same kind of MakeNoise() (moew) implementation. You might think, "well, we can just derive from the concrete class Cat, and override the Eat() method with our own AllyCat.Eat() implementation" and you're right, you can. However, extending behavior through hierarchal inheritance should be avoided. Not only that, designs like this can lead to duplicate code.


Instead, you should compose classes with isolated algorithm implementations. The goal is to separate varying-code from non-varying code. A quick way to identify non-varying code aspects of your classes is through "has-a" relationships. A Dog "has-a" distinct eating behavior, a Cat "has-a" distinct eating behavior, an AllyCat "has-a" distinct eating behavior, so on and so forth... From our classes and implementation, we have noise behaviors and eating behaviors.


The Solution

The solution to basic problems is to implement a Strategy pattern. Consider the following architecture:

And taking a peek in some of the Cat, Ally Cat and Dog code:




All that we have done with this new architecture is delegate the "making noise" and "eating" to behavioral classes that specifically handle the task. We have delegated control to the behavioral classes. This is a much better extensible and coherent design and often leads itself to better to code reuse.


Whenever we create classes that are composed of behavioral actions, we call these compositions. Classes such as Dog, Cat, and AllyCat are compositions of behaviors and gain their behavior through composition, not inheritance. Inheritance (like the previous architecture) can lead to unintended consequences when fiddling with the superclass and is more prone to breaking existing code.


Common Uses

  1. Algorithm Families – A general case different algorithms need to run depending on a particular situation.
  2. Sorting - Used in sorting when different types of sort algorithms need to be applied to a collection. For example, List.SortBy(FirstNameStrategy)
  3. Behavioral – Used when many distinct "behaviors" are expected of derived classes.


Naming Keywords for the pattern

When naming your interfaces, here are some keywords to include in the naming of your strategy

  • General: Strategy, Algorithm
    • Example: CaliforniaTaxStrategy
  • Behavioral: Behavior, Action, Style
    • Example: BarkBehavior


Principals to take away from this strategy

  • Look at your application, and analyze the classes that are producing the Design Smell. Take those classes, and analyze the functionality of the classes that are producing this type of Design Smell. Create a separation of varying code and non-varying code (such as specific behaviors that tend to stay the same across all classes or with every new requirement). Once you've identified the non-varying code, then you have an opportunity to extract the behavior from the class and isolate it in its own behavioral family.
  • Use composition rather than inheritance. Composition is encapsulating several behavior/strategies in one class to perform its work. Classes should not inherit their behaviors from base classes; instead they should be composed of behaviors/strategies.
  • Has-A relationships are good indicators that strategy pattern can be used.


Formal definition of the strategy pattern

The Strategy Pattern defines a family of algorithms, encapsulates each one, and makes them interchangeable. Strategy lets the algorithm vary independently from clients that use it.


This blog post is a little dry because I'm really sleepy, I'll try updating it to make it a little more clear later when I have more time. But I hope some of you understand! Later I'll show you how to improve this architecture.

Filed Under [ Design Patterns ]
Design Toolbox

Here's a quick summary of Design Guidelines for your Design Toolbox.

Object Oriented Basics

  • Abstraction
  • Encapsulation
  • Polymorphism
  • Inheritance


Object Oriented Principals

  • Encapsulate what varies (think strategy pattern)
  • Favor composition over inheritance
  • Program to interfaces not implementations


Object Oriented Patterns

  • Strategy – Defines a family of algorithms, encapsulates each one, and makes them interchangeable. Strategy lets the algorithm very independently form clients that use it.
  • Observer – Defines a one-to-many dependency between objects so that when one object changes state, all its dependents are notified and updated automatically.
  • Decorator – Attaches additional responsibilities to an object dynamically. Decorators provide a flexible alternative to sublcassing for extending functionality.
  • Factory Method Pattern – Defines an interface for creating an object, but lets subclasses decide which class to instantiate. Factory Method lets a class defer instantiation to subclasses. Creates objects through inheritance.
  • Abstract Factory Pattern – Provides an interface for creating families of related or dependent objects without specifying their concrete classes. Creates objects through composition.


General Design Principals

  • Identify the aspects of your application that very and separate them from what stays the same.
  • Program to an interface, not an implementation.
  • Favor composition over inheritance.
  • Strive for loosely coupled designs between objects.
  • Classes should be open for extension, but closed for modification.
  • Depend on abstractions. Do not depend upon concrete classes.
  • Follow the Dependency Inversion Principle Guidelines
    • No variable should hold a reference to a concrete class.
      • If you use new, you'll be holding a reference to a concrete class, use factories.
    • No class should derive from a concrete class.
      • If you derive from a concrete class, you're depending on a concrete class, derive from abstractions.
    • No method should override an implemented method of any of its base classes.
      • If you override an implemented method, then your basee class wasn't really an abstraction to start with. Methods defined in your base class were meant to be shared by all subclasses.



Filed Under [ Design Patterns ]
General Database Design Guidelines and Naming Conventions

Here are some helpful tips on database naming conventions. Consistency, readability, maintainability, and extensibility are some of the most important factors when designing new databases. In this blog I'll go over some conventions I use to keep myself consistent. If you have any conventions you follow or ways to improve these conventions, let me know. :)

Entity Class Naming

The name of our entity classes should be in the singular form, for example Account, Customer, or User (for a user accounts table). Plural names (such as Accounts, Orders, and Order Details) aren't good candidate for entity names because 1) plural names don't grammatically fit well when reading relationships that are self-referencing and one-to-one 2) it reduces the readability of SQL statements when fully qualified names the WHERE clause. To Illustrate:

/* Using singular form */

SELECT * FROM Account WHERE Account.ID = 1;

 /* Using plural form */

SELECT * FROM Accounts WHERE Accounts.ID = 1;


If you ask me, the singular form reads much better in the WHERE clause, but the plural form performs better in the FROM clause. When creating complex SQL queries, readability in the WHERE clause tends to outweigh the benefits of readability in the FROM clause. This is why singular table names are generally better. Furthermore, the name of the entity should be representative of a single row in the table. Names like History, Schedule, and Table are not descriptive enough.

For certain types of entities, special keywords should be contained in the naming of the entity. Below is a list of special entities and associated key words that should be considered a part of the naming scheme.

  • Tracking History: History, Historical, Event


Attribute Naming

Below is a small list of naming guidelines for naming columns based on the type of data they hold.

  • Identifiers: Number (or No), Code, Identifier (or Id), Tie-Breaker
  • Categories: Type, Method, Status, Reason
  • Counts: Count
  • Dimensions: Length, Width, Height, Weight
  • Amounts: Amount, Price, Balance
  • Factors: Rate, Concentration, Ratio, Percentage
  • Specific Time Points: Timestamp, DateTime, Date, Month, Year
  • Recurrent Time Points: TimeOfDay, DayOfWeek, DayOfMonth, DayOfYear, MonthOfYear
  • Intervals: Duration, Period
  • Positions: Point, LineSegment, Polygon
  • Texts: Name, Description, Comment, Instructions

Try to avoid abbreviations; it may likely confuse business people using the database.

Natural Keys vs Surrogate Keys

When choosing the primary key for a table, often in designs, natural keys occur in the business problem. For example, if we're modeling a Person table in our database we might be inclined to use the Social Security number (a natural key) of a person as the primary key in the Person table. This isn't a bad design, since everyone in the US should have a Social Security number; however, keying the Person table with a Social Security number as the primary key doesn't lead to an extensible design. What happens if the system and database we're designing for needs to handle people who are not US citizens or people who don't have a Social Security number? As you can see, using a Surrogate Key named PersonId with an identity constraint as our primary key is a much better extensible database table design than using a natural key. In most cases, even if the natural key is truly unique, I would still use a Surrogate Key.


That's all for now! If I come think of some more, I'll add them to this blog post later. :) Keep in mind there is no "best practice" because any best practice can be turned into a worst practice if the situation changes. The point is the schema design of every database should be well thought out. Being consistent in your designs help leads designs to be readable and maintainable. Extensibility leads your designs to be changed and refactored when business processes change.

Filed Under [ Databases Tips & Tricks ]