Kerpau!

This particular sysadmin is wrapping up a 70+ hour work week. Ugh! I hope you all had a more relaxing week than I did. Happy SysAdmin day!

The stop error 0×00000077 is a KERNEL_STACK_INPAGE_ERROR and means that a page of kernel data could not be read into memory from the paging file. Additionally, the parameter 0xC000009D is a STATUS_DEVICE_NOT_CONNECTED error and is the result of the controller not seeing the hard disk drive.

Some causes of this condition are:

• Outdated or faulty disk controller firmware
• Outdated or faulty disk controller driver
• Bad disk block in the paging file
• Improper SCSI termination
• Loose or bad cabling between the disk(s) and disk controller
• A disk controller error
• Lack of non-paged pool resources

Some possible resolutions to this condition are:

• Update disk controller firmware
• Update disk controller drivers
• Verify cabling between disk(s) and controller
• Verify proper SCSI termination

In all cases you should run a “CHKDSK X: /F /R” to repair any file system errors on the disk. If you have an additional disk on the machine you may want to rebuild the paging file.

Go to System Properties > Advanced > Performance > Settings > Advanced > Virtual Memory > Change and configure No paging file for the existing drive. Select one of the other drives and configure System managed size. This effectively removes the paging file from one disk and creates it on another disk. You may get some warnings regarding the inability to create a dump file when doing this. Just click past them and finish the configuration. Reboot the server when prompted. When the system finishes rebooting, run the CHKDSK X: /F /R command and reboot again when prompted. When the system finishes the CHKDSK process, check the application log for the CHKDSK results and then move the paging file back to the original drive using the previous steps. A successful completion of these steps results in a fresh paging file on a known good file system.

CHKDSK doesn’t create a log file but it does write an entry to the Windows application log.

Event Type: Information
Event Source: Winlogon
Event Category: None
Event ID: 1001

You would think the system log would be more appropriate. That’s where I looked first. But there I go again…expecting things to make sense. What was I thinking!

Windows Media Player handles sound differently when the session is connected via Remote Desktop. If you are connected using RDP/RDC, exit the session and reconnect using “mstsc /console” and then try playing the file again. Assuming that everything else is running properly this will work for you. Here are the rest of the details on the error message:

C00D11BA: Cannot play the file
Windows Media Player cannot play the file because there is a problem with your sound device, such as a sound card or sound controller. You might encounter this error message for one of the following reasons:
Your sound device is in use by another program. Quit other programs that might be using your sound device, and then try to play the file again.
Your sound device requires an updated driver. To determine if an updated driver is available, see the Windows Update Web page at the Microsoft Web site, or see the sound device manufacturer’s Web site.
The selected sound device does not support Secure Audio Path (SAP). If you have multiple sound devices installed on your computer, try using a different one.
Your sound device is not functioning properly. To troubleshoot the problem, see the Sound Troubleshooter in Windows Help or refer to your sound device’s documentation.
You do not have a sound device installed on your computer. Install a sound device, and then try to play the file again.
To use a different sound device
On the Tools menu, click Options, and then click the Devices tab.
Double-click Speakers, and in Audio device to use, click a different device.
Error ID = 0xC00D11BA, Condition ID = 0×00000000

I’ve had the opportunity to work with a lot of sysadmins of varying experience levels lately and think I have it all figured out. Inexperienced sysadmins expect things to work. Experienced sysadmins expect things to not work. This fundamental mindset leads to vastly different behavior patterns among the two types. If a sysadmin expects a system to fail, s/he will be more likely to perform regular backups, design redundancy into solutions, read the manuals before deployment, test a solution before deployment, test a solution after deployment and so forth. The inexperienced sysadmin reads the marketing materials, believes every word that comes out of the salesperson’s mouth, doesn’t plan for failure.

So when the system ultimately fails, the experienced sysadmin has an entire array of options to choose from. Like backups, failovers and expertise gained from reading the manuals. The inexperienced sysadmin has to resort to trial and error fixes on a live system with no fundamental understanding of the technology. This usually make the issue worse and leaves them in their last resort scenario - bugging tech support. Not good if your job depends on it.

Oddly enough, I found this piece of advice on The Simple Dollar post on Wealth.

Err on the Side of Simplicity Where Possible

It was mentioned in the context of money but is definitely applicable to system design. It’s really a variant of Occam’s razor and one I’ve used many times when considering options in design, deployment and maintenance of complex systems.

All things being equal, the simplest solution tends to be the best one