The key is located on the installation CD disk, in the file:
/i386/WINNT.SIF
Microsoft really sucks. Even their DotNet CLR runtime error reporting sucks. Last week, a user in London called me and reported a startup problem with the service I support. I could see the error in the event log as:
EventType clr20r3, P1 ripgrcubeaggregatoranalytic.exe, P2 3.3.0.2, P3 46267b76, P4 log4net, P5 1.2.9.0, P6 42a6f2e9, P7 259, P8 0, P9 system.typeinitialization, P10 NIL
This error message is completely completely utterly useless. Somehow this runtime error even avoided getting trapped by my service’s unhandled exception handler.
After endless iterations of testing with a previous version followed by more testing, I finally tracked down the cause of the problem to the London user’s messing up of the service’s App.Config file. He put in a one byte code- which invalided the entire App.Config xml- and threw the DotNet application into a fit.
So if you see this runtime problem, first check the App.Config.
A short tip to adding a new “Send To” menu item in Windows-
Open up \Documents and Settings\All Users\Send To.
Dropping a shortcut to an application to this folder will enable the application to be a target of a Send To right click.
Something even as old school as the ODBC Data Source Administrator window (also known as the ODBC control panel) reviews to me new unknowns.
A client in New York wanted an Excel spreadsheet to connect to a company database down in North Carolina. Only problem is- how do you do that? Turns out- Microsoft’s ODBC Data Source Administrator saves the day (disclaimer: I am not a Microsoft cheerleader. I am a software/hardware agnostic solutions provider.) In my entire work experience, I’ve worked with clients who had internal in-house databases (databases on a machine somewhere on the company network). Whenever an in-house application wanted some data, chances were- it was in a database somewhere within the networked confines of the company, and you had a reasonable chance of getting at the data with help from a local DBA.
But today’s case was interesting. The client had sent the database server machine offsite- to a 24×7 data warehousing facility and he usually logins to the machine remotely using Terminal Services. So how can a client machine in NY seamlessly get data from a machine in North Carolina?
Turns out- oh, it’s not that hard. The database server machine name has an alias- say, cougar.acme.com. And [...]
I find the following instructions useful when I’m converting a machine from Windows to Linux or vice versa- or if you just want to wipe out the disk entirely before dumping it out on the sidewalk:
Get a boot disk from bootdisk.com or from shrum.net
Get the DOS boot disk 98, OEM edition with RAM disk.
Get the newfisk as well.
Low level format the disk with the new fdisk.
Then high level format drive C.
Install operating system.
If the machine previously ran Linux and you want to reinstall Windows on it (why why why?), then you’ve to remove the Master Boot Record (MBR) from the hard disk as well (else it’ll try to start up GRUB). Use the fdisk command below to wipe out the MBR as well:
fdisk /mbr