From monthly archives: October 2009

We are pleased to present below all posts archived in 'October 2009'. If you still can't find what you are looking for, try using the search box.


My Letter to Senator Hagan Regarding the American Health Security Act of 2009

Senator Hagan - I am writing this letter to urge you to support Senator Bernie Sanders' American Health Security Act of 2009, which is a Single Payer health care bill.  I have no delusions of this bill's ability to pass the Senate - it surely will not. 

The reason to vote in favor of it is to measure the support in the Senate of a single payer style health care bill.  This is something that likely will not be able to pass for decades, but what Sen. Sanders is doing is important because it gives us a baseline to see how many votes we have now, and how many we need to work for in the future.

I am currently 32 years old.  I hope to see a single payer system implemented in the USA before I die.  This is a fantastic first step.

Please show the rest of the country that North Carolinians are progressive Southerners -- not knee-jerk-reaction head-in-the-sand conservatives.

Please support the American Health Security Act of 2009.


Mystery of the Server 2008 + IIS7 + OLE = "MDAC Not Installed" Error

Talk about barking up the wrong tree!

I just solved a very peculiar error regarding migrating old ASP.Net OLEDB Excel/Access file access code to a new 64-bit Windows Server 2008 under IIS7.  The first steps for migrating this application were obvious.  The application pool needs to run under 32-bit compatibility mode, the pipeline needs to be classic, etc.  But when we got to the Excel export functionality, all hell broke loose.  No matter what we did, we would get the following exception.

Exception of type 'System.Web.HttpUnhandledException' was thrown. [System.Web.HttpUnhandledException]
The .Net Framework Data Providers require Microsoft Data Access Components(MDAC). Please install Microsoft Data Access Components(MDAC) version 2.6 or later. [System.InvalidOperationException]
Retrieving the COM class factory for component with CLSID {2206CDB2-19C1-11D1-89E0-00C04FD7A829} failed due to the following error: 800703fa. [System.Runtime.InteropServices.COMException]

The error was a red herring.  The problem is not that MDAC is not installed – it is far more obscure.  WDAC (MDAC's successor) is included in Windows Server 2008 and has plenty of backward compatibility built into it.  That part of the equation is perfectly fine.  In fact, if you run console/forms apps, you probably will never see this problem.  It is only when you are running ASP.Net code and use a custom identity for the Application Pool (possibly some other situations too) that this error occurs.

By doing a ProcMon trace, I was able to pin down the problem.  If you follow all the steps that w3wp.exe performs, you will see one really weird line.

Line from ProcMon 

Okay, the unknown result code is weird enough, but ProcMon couldn't even tell me which registry key it couldn't find!  Examining the stack trace confirmed that this was the only request logged that had ole32.dll loaded, plus it showed ole32.dll throwing an error, so it really appeared to be related to my problem.

ProcMon stack trace

Thankfully, the Great Gazoogle did not let me down.  It turns out that 0xC0000425 indicates that an application was attempting to access a registry hive  after it was unloaded.  What the heck?

This is a good time to explain how the registry works at a very high (and simple) level.  Each registry hive is a self-contained database in an independent file in the file system.  A good example is NTUSER.DAT located in your user profile folder.  That's your very own HKCU.  Not all of the registry is always loaded all the time.  This is what allows Windows to move your profile around, or copy your profile (registry included) without having to do individual registry read/writes (much slower).

If HKLM or HKCR were unloaded while Windows was running, your computer would probably just freeze up completely, so those were not good candidates for this problem.  It had to be a user hive.  Since it was the application pool identity that got this error, it had to be that user's profile.  But how can its own registry get unloaded in the middle of execution?

I found the answer at a Sun support forum, of all places.  It turns out that in previous versions of Windows, you could download a program called UPHClean that would help unload user profiles when they were no longer needed (supposedly) to avoid the annoying user profile deadlocks that would sometimes occur, causing you to have to use a temporary profile, instead of your own user profile.  If you haven't experienced this error before, you are lucky!  It is rare, but when it occurs, it is very annoying.  It's apparently more common on Terminal Servers than other servers, from what I've seen.

Well, in Server 2008, the functionality of the UPHClean service has been rolled into the User Profile service, which always runs.  So Server 2008, on the whole, more aggressively shuts down dangling registry handles when a user logs off.  The aforementioned support forum participant recommended shutting off the UPHClean functionality entirely.  I'm not a big advocate of fixing shovel-sized problems with a back ho, so I decided to dig a little more.

To see if this really was the cause of my woes, I searched for Event ID 1530 in the event log to see a user's HKCU was ever forcefully unloaded.  Yes, there have been occurrences, yes the process involved was w3wp.exe, and yes the SID corresponds to the application pool identity.  I'm getting closer to a solution!

Windows detected your registry file is still in use by other applications or services. The file will be unloaded now. The applications or services that hold your registry file may not function properly afterwards. 

2 user registry handles leaked from \Registry\User\S-1-5-21-1129910693-4165624395-2147873099-2135_Classes:
Process 6632 (\Device\HarddiskVolume1\Windows\SysWOW64\inetsrv\w3wp.exe) has opened key \REGISTRY\USER\S-1-5-21-1129910693-4165624395-2147873099-2135_CLASSES\Wow6432Node
Process 10144 (\Device\HarddiskVolume1\Windows\SysWOW64\inetsrv\w3wp.exe) has opened key \REGISTRY\USER\S-1-5-21-1129910693-4165624395-2147873099-2135_CLASSES\Wow6432Node

So why was this happening?  Clearly my application has not exited.  Why does the User Profile Service think it can arbitrarily close that registry hive while my application pool is still doing work?  I'm guessing that UPHClean detects the open handles and when enumerating loaded profiles, sees that the user's profile is not loaded, so decides that those open handles must be dangling and should be forcefully closed.

The solution to preventing this problem turns out to be a very simple configuration setting in IIS7's Application Pool Advanced Settings.  To fix this problem, all you need to do is enable profile loading in IIS.  What this does is tell IIS to completely load the user profile for the entirety of the execution of the application.  The default approach is the IIS6 approach, where the profile is not loaded when the user is impersonated by the IIS service.  In IIS6, this was okay because on Server 2003 UPHCLean was an optional download and not installed by default.  If it's not installed, it can't unload the hive, obviously.  :-) I would imagine if you did install it on 2003, you would have a similar problem in a similar situation.

IIS7 advanced settings

So, in conclusion, no profile loading means premature registry unloading, which means no OLE, no MDAC, and, therefore, no Excel/Access.

Mystery solved.


Fixing Slow .Net Compact Framework Windows Mobile Compilation Times

A colleague of mine found a great article with a tip to significantly speed up the compilation time of large .Net Compact Framework projects.  I was just living it with, thinking there was nothing I could do.  I'm so glad he found that article!  It is helping speed up development of my mobile hobby projects significantly.  The slowness is due to a verification step that ensures that your application complies with its target.  Obviously during debugging, this step does not need to be executed every single time you build!  The article suggests creating a new environment variables, but I think a better approach is to use the $(ConfigurationName) variable.  When I compile for release, I want this check.  For debug, I don't.  So go read the article!  Then, if you like, take my suggestion and change the condition to...

Condition="'$(ConfigurationName)' != 'Debug'"


Sunday Night Football

I didn't think anything could be more annoying than the Monday Night Football theme song.  Then NBC created a carbon copy (but worse) semi-country, semi-rock song sung by somebody sort of famous, but highly annoying for Sunday night.  Because, yes, it is entirely MNF's song that makes it successful in prime time and not an exciting football game itself!

Teevee executives are retarded.

(Yes, I know NBC's SNF is not exactly new, but this has been something I've been meaning to complain about since they took over in 2006. lol.)


Mystery of the 1395 Error During .Net Framework 3.5 SP1 Installation

I have had a heck of a time lately with the SP1 for the 3.5 framework.  Where I work and at home, the installation  has failed on a total of FIVE computer!  Five!  Each time was a little different.  The Google was able to give me a solution for most (usually silly dependencies failing, such as SP1 for Visual Studio), but one, in particular, was a little more devious, on a 64-bit 2008 server.

I kept getting 1395, which is a pretty generic error.  By digging through a lot of logs, I saw the error was occurring during the installation of the Visual C 9.0 Redistributable, so I downloaded it to install it manually.  I immediately got an error when it was trying to install an assembly.

Error 1935.An error occurred during the installation of assembly 'microosft.vc90.atl'

Included in the message was also HRESULT: 0x80070005, which indicates "access is denied."

I ran Procmon and found there is a folder where access was denied for SYSTEM.  The folder where access is denied is in winsxs (C:\Windows\winsxs\InstallTemp) and the default permissions indicated that read only access is probbaly normal for SYSTEM, as it had full control for TrustedInstaller.  So I'm guessing that it may actually be a bug in the VC90 installer, but either way, I added Full Control to SYSTEM and the problem cleared.



Does the Petroleum Lobby Think America is Retarded?

My teevee just told me that climate reform will cause gas prices to raise above $4/gal (no evidence was provided, of course).  This commercial was paid for by some petroleum lobby, as indicated in the very fine print. 

That's odd.  I seem to remember huge gas price increases happening without any climate legislation pending not too long ago.  And if I remember correctly, the prices went down sharply as soon as people started getting smarter about wasteful gas spending, which was a necessity due to the declining economy.   All of that had nothing to do with reducing carbon emissions.

Why are lobbies not required to do an oral endorsement, like politicians?  They should.  "We're America's petroleum lobby and we paid for this message."  Not everybody reads the fine print, like I do.

You know, if you think about it, they are basically threatening America with extortion.  Force us to clean up, we raise your prices.  Well to that I say, I call your bluff, and here's a middle finger you can sit on.


Let's Blow Up The Moon!

This morning, NASA crashed a probe into the moon in order to stir up debris to figure out what that part of the moon is made of.  The best (or worse, based on your perspective) case scenario of the impact was for the probe to be slightly less powerful than the usual meteors that crash into the moon dozens of times per year.  The result was not the giant plume of debris the scientists had expected or hoped for, but it still yielded a lot of useful information.

So, this afternoon, a coworker of mine absolutely went batshit crazy on this issue.  "What right do we have to crash a rocket into the moon?" he cried.  "What if there was some underground gas that was flammable and it caused some sort of explosion?!"

Wow.  Just, wow.  This is a perfect example of why the USA needs massive science education reform.  I argued with him for a little while, but he just kept throwing logical fallacies at me.  In particular, he seemed to favor arguments from personal incredulity.  When I confronted him with the fact that the moon gets battered worse than that regularly nearly every week, he actually exclaimed, "but that's nature!  This wasn't!"

If there was some sort of explosive gas trapped under the moon that could actually cause harm to the moon or the earth by an impact that small, our little planet would have been wiped out billions of years ago!  On second thought -- I didn't ask -- but maybe he doesn't believe the earth is that old.

I had no idea this was a controversial issue with anybody in the entire world.  I can't believe I have to say this, but the moon was in absolutely no danger and neither were we, as occupants of the moon's closest celestial neighborI really geek out at stuff like this.  I love science!  I love reading about new discoveries, particularly in astronomy and physics!  It really burns me up that there are people so ignorant about science that they just want to stop it whenever they don't understand something.  I probably shouldn't tell him about the overblown hype of potential microscopic black holes that might be created at CERN's LHC.

So anyway, I want to end this blog post on a light hearted note, so here's a visit back to the world's greatest skit show, where they dealt head on with the controversial issue of blowing up the moon!


Avian Waves is Back Up!

Apparently the hardware that my web server's VPS lives on completely died.  I mean died so bad that VPSLand didn't have any way to restore it!  Luckily I take nightly backups of everything important, so the website is back with no loss of content.  Unfortunately, SQL Server 2008 Express's installer has a serious amount of bugs that took me about 6 hours of debugging to figure out.  The entire site is driven off SQL 2008, so I had no way to get the site back without it.  It seems something that was in VPSLand's standard deployment image made SQL 2008's installer unhappy.  It took a lot of registry deletions to get it to work.  More about that later (if I remember).

Anyway.  The site is finally back up!  Hooray!

Recent Comments
  1. Re: It's Coming Any Day Now...
    Tim: Awesome to hear. Can't wait to check it out.
  2. Re: RD Tabs Security Advisory - 2.0 and 2.1 Beta
    Roman: Hi admin having same materiel as i need. Also get some extra stuff here: [url=""]Patch Applications...
  3. Re: RD Tabs Security Advisory - 2.0 and 2.1 Beta
    Roman: Hi admin having same materiel as i need. Also get some extra stuff here: Patch Applications
  4. Re: 3.0 is coming...
    Sean: Great news, can't wait!
  5. Re: DPM 2016 + SQL 2016 and "An unexpected error occurred during the installation" ID: 4387
    Funny Guy: To add my 2 cents - after a day of fight it appears that DPM installation uses WMI queries to detect...
  6. Re: DPM 2016 + SQL 2016 and "An unexpected error occurred during the installation" ID: 4387
    Funny Guy: To add my 2 cents - after a day of fight it appears that DPM installation uses WMI queries to detect...
  7. Re: DPM 2016 + SQL 2016 and "An unexpected error occurred during the installation" ID: 4387
    Funny Guy: To add my 2 cents - after a day of fight it appears that DPM installation uses WMI queries to detect...
  8. Re: DPM 2016 + SQL 2016 and "An unexpected error occurred during the installation" ID: 4387
    kAM aCOSTA: Thanks Edward !!!
  9. Re: 3.0 is coming...
    Dave: Very Cool!
  10. Re: In VB.Net, sending output to the console from a Windows "Forms" application
    clochardM33: Glorious