Saturday, January 14, 2006

I am done troubleshooting the server

I have utterly and completely exhausted every avenue I have trodden down in an effort to get this machine going. I have swapped out (many, many times):
- memory (266Mhz DDR SDRAM/ECC/registered/CL2.5)
- mobo (Super Micro P4DL6)
- power supply..twice
- CMOS battery

I have removed CPUs. I have run single CPU configs. I have swapped the position of the existing CPUs. I have applied new thermal paste to a CPU. I have bought new memory. (I have returned new memory). I have connected storage types (ide or scsi) individually. I have connected storage types together. I have bought a new power supply. (I have returned a new power supply). I have used a different power outlet. I have removed the board from the case entirely in combination with a second power supply to make sure there was no short with the power or reset connectors from the original case.

I normally start with no storage, with no power connection or IDE/SCSI connection to the board. From there, if I get a clean boot and no freeze ups, I will add my DVD drive w/a Fedora install disc. After booting, the system will either make it past the initial Linux boot process or freeze during the Fedora install process. If the box makes it past the Linux boot process and doesn't hang, I am compelled to add storage. So, I alternately try adding SCSI or IDE storage, whatever suits my displeasure. SCSI freezes up on channel A, so I try channel B. Still freezes. I try the primary IDE controller, then I try the secondary IDE controller. I swap memory positions and brands while I do this, while I grid the combinations on paper, in order that I don't miss one.

So far, it has always frozen, either five minutes after booting or later, like fifteen minutes down the line when I almost get my hopes up that I've found the silver bullet and that it will actually work this time. 99% of the time it has frozen in a different place during the boot process or Fedora install.

The only unchanging constant are the CPUs. I am lead, inexorably, to the fact that these CPUs MUST be the source of the problem..everything else around them has been swapped out.

I must feel some joy at this discovery. However, it simply doesn't make sense that both CPUs would burn out. This doesn't seem logical. I believe that if I go through the effort of purchasing CPUs from Ebay that, in the end, I will be confronted with the same issue, will have wasted $150 or so for new CPUs and be left with final disappointment. But, I feel I have to resolve this chapter of my ridiculous life, so I plod on to my destruction.

I am done with troubleshooting the server.

UPDATE: if anyone has encountered and solved a similar problem, please let me know. Maybe I'll dig this mutha out of the trash bin and try once more! Thanks!

Thursday, January 12, 2006

SQLAllocHandle on SQL_HANDLE_ENV failed

Ah, the ever wonderful:
Microsoft OLE DB Provider for ODBC Drivers error '80004005'
[Microsoft][ODBC Driver Manager]Driver's SQLAllocHandle on SQL_HANDLE_ENV failed

The error happens on a brand new Oracle 9i installation on a Win2K IIS server. The specific context is a web-based database query to Oracle via the Microsoft ODBC driver. There are a few steps that have solved the problem for me:
1) reinstall the Oracle client. Specifically:
- Remove all the Oracle components
- Delete the Oracle9i directory
- If you've made a request to the IIS server that includes a call to Oracle, IIS will be hanging on to oci.dll, the Oracle Call Interface driver, so you'll have to reboot in order to delete the locked file. Reboot!
- After rebooting and removing the Oracle9i directory, reinstall Oracle.

2) Make sure to assign IUSR_servername R&X permissions on the Oracle9i directory

3) Edit the following key: HKEY_LOCAL_MACHINE\ROOT\SOFTWARE\Microsoft\MSDTC\MTxOCI
Change the values of the three keys:
a. OracleOciLib - change from ociw32.dll to oci.dll
b. OracleSqlLib - change from SQLLib18.dll to orasql9.dll
c. OracleXaLib - change from xa73.dll to oraclient9.dll

4) Reboot again!
5) Test to make sure you don't get the evil error.


Wednesday, January 11, 2006

CS0007: Unexpected common language runtime initialization error -- 'Catastrophic failure '

Update: apparently, the reason why this error occurred was that my system had some security lockdown permission changes which conflicted with the list of patches below..hence the need to make those permissions changes in steps 4 and 5 below. Harumph.

Argh. One of the recent set of MS security hotfixes has broken with the following error:
CS0007: Unexpected common language runtime initialization error -- 'Catastrophic failure '

I upgraded my Win2K server with the following patches:
KB905915 IE6 SP1
KB902400 2K
KB908523 2K
KB912919 2K
KB891861 2K SP4 Rollup
KB890830 Dec Malware Removal

I've found a workaround here:

Here is the text of the workaround:
Running ASP.NET application was giving
Compiler Error Message: CS0007: Unexpected common language runtime initialization error -- 'Catastrophic failure'
There were some problems with the permission on the aspnet account. Later we found that EVERYONE group was missing READ permission on c:\windows\registration folder. Below given are the steps to check the permissions of aspnet account at various places.
Following are Generic Steps that we can take to fix the various issues related to ASP.NET that you are seeing on different Windows 2000 SP4 boxes which we believe is happening because of the security patches you installed.

Please make sure that the ASPX pages run under SYSTEM account before proceeding further with following steps
Steps 1 and 2 would make sure that you get rid of event id: 1007 and 1084
Follow Step 3 if you are getting if you are getting "Compiler Error Message: BC32400: Class 'CLSID_CorSysWrite_SxS could not be created 'Catastrophic failure'
Steps 4 and 5 are for "Compiler Error Message: CS0007: Unexpected common runtime initialization error -- 'Catastrophic failure'"

1. Running ASPNetRegIIS –ua followed by ASPNetRegIIS –i from the framework folder.

2. Make sure that ASPNET account has got permission as per following matrix
Location Access type Account Comments installroot\ASP.NET Temporary Files Read/write Process or configured impersonation. This is the location for dynamically compiled files. Beneath this location, application code generation takes place in a discrete directory for each application. The root location itself can be configured using the tempDir attribute of the section. systemroot\assembly Read Process or configured impersonation. This is the location of the global assembly cache. systemroot\system32 R Process Contains system DLLs loaded by the .NET Framework. systemroot\temp Read/write/delete Process Used for web services support. userprofile directory Read/write Process Used by the global assembly cache lock files and the common language runtime security configuration caching mechanism. If the user profile directory for the account doesn't exist, ASP.NET will use the default userprofile directory.application directory Read Process or configured impersonation. This is the location for application files. installroot hierarchy Read Process or configured impersonation ASP.NET must be able to access the system assemblies referenced in the Machine.config file in the config subdirectory under installroot. Default Web Site monitoring. Read Process Used for file change notification monitoring
3 Make sure that ASPNET account has got read permission on following keys
4. In the %windir%/registration folder, make sure that the Everyone group has READ permissions.
- In the advanced security properties of the .clb files in the %windir%/registration folder, make sure that the Inherit from parent the permission entries that apply to child objects. Include these with entries explicitly defined here option is selected.
- Make sure that the Everyone group has one of the following permissions: Traverse permissions (“List Folder Contents”) on all parent directories (%systemdrive%, %windir%, and %windir%\registration), or The Bypass Traverse Checking permission is selected.
5. Running RegSvr32.EXE mscoree.dll from the C:\winnt\system32
Feel free to drop me a line or ask me a question.