Windows Server's three major crashes and avoidance methods

There are many ways to crash Windows Server, but most of them fall into three categories: old anti-virus software, incompatible storage drivers, and too many filter drivers. After analyzing about 1000 crashes from nearly a decade in the world, I can confirm that these are the hidden dangers you want to avoid.

Let's take a closer look at the details of these three server system crashes and introduce the best ways to avoid them.

Anti-Virus

So far, the most common Windows Server crash has been caused by older anti-virus software. All anti-virus software uses device drivers, more specifically "filter drivers" to intercept I/O (read/write) requests and perform additional checks. The anti-virus software driver compares the checked content with known virus definition files to ensure that no viruses are infected.

Filtering drivers contain kernel-mode code that interacts with the underlying kernel functions and data structures of the operating system. These functions and data structures include those predefined parameters and data that are expected to be rendered when the corresponding device driver is called. Types of. If the data type passed by the function is incorrect or the number of parameters is incorrect, an error occurs that causes the system to crash in kernel mode.

The problem arises when developers modify these kernel functions or data structures between different versions of the operating system (such as service pack updates or new versions of the operating system). Although Microsoft did a good job of testing device drivers for compatibility with all operating system changes, it apparently did not test third-party device drivers to ensure they were compatible. Therefore, when the old anti-virus driver accidentally encounters these changes, it will eventually cause the system to crash. Other filter drivers are also susceptible to this problem, but anti-virus drivers are the most vulnerable.

Let's look at an example:

Here is a system crash with Stop 0x8E bugcheck -KERNEL_MODE_EXCEPTION_NOT_HANDLED. Use the command in the Windows debugger! Analyze –v shows its stack mode. Reading from the bottom up, we see a function call of NtCreateFile, which finally introduces buggydrv, which leads to bugcheck. Use the command! Lmi buggydrv can show that the driver date is 2006, while the operating system Windows Server 2003 SP2 was released in 2007. Now we know that the old version of the anti-virus driver did not test the new version of the operating system.

nt!KeBugCheckEx+0x1b

nt!KiDispatchException+0x3a2

nt!CommonDispatchException+0x4a

nt!Kei386EoiHelper+0x186

Buggydrv+0x13059 <--Filter driver causing system crash

buggydrv+0x8390

buggydrv+0x8809

buggydrv+0x2940

nt!IofCallDriver+ 0x45

nt!IopParseDevice+0xa35

nt!ObpLookupObjectName+0x5b0

nt!ObOpenObjectByName+0xea

nt!IopCreateFile+0x447

nt!IoCreateFile+0xa3

nt!NtCreateFile+0x30 <--Operating system call CreateFile

nt!KiFastCallEntry+0xfc

In this example, such a system The crash has been identified by the vendor as a known issue and documented, and new versions of anti-virus software can be used to avoid system crashes. In fact, the vast majority of Windows Server crashes you've encountered have happened to others, and their solutions are usually recorded somewhere on the Internet. Therefore, it is important to remember that even just a service pack update. When updating the operating system, it is also necessary to confirm with the third-party vendors whether there is a corresponding software update.

Storage Drivers are not compatible

Another most common system crash is caused by incompatible storage drivers. As you know, third-party storage vendors provide device drivers to control their host bus adapters (HBAs) and access storage devices. Vendors like Qlogic, Emulex, and Hewlett-Packard (HP) have different device drivers, but they all rely on Microsoft's Storport driver. The Storport driver provides a common set of programs that are used by specific vendor drivers to perform I/O operations.

This problem occurs in a similar way to the incompatibility of anti-virus software drivers. When vendors modify their dedicated drivers, they must re-test with the current version of Storport to ensure they are still compatible. By the same token, when updating the Storport version, all HBA drivers must be retested to ensure they are still compatible with the new Storport driver. In Windows Server 2003, this is a real challenge when you need to consider more than 50 patches for Storport.

The rule of thumb is to check with your third-party vendor whether there is a corresponding update to the HBA driver before updating the Storport driver, and vice versa. How do I know which storage driver is dependent on Storport? Fortunately, there is a free tool called Dependency Walker (depends.exe) that reveals dependencies between drivers.

After downloading and unzipping, run depends.exe and use the file drop-down menu to select the driver you are interested in. In this example, I chose the driver Hpcisss2.sys, which is applied to HP's disk arrays. As you can see below, the tool displays, driver Hpcisss2 dependent on STORPORT.SYS and Ntoskrnl.exe.

excessive filter driver

The third most common Windows Server The type of crash is related to the stack overflow condition when too many care drivers are installed. Any driver that can intercept I/O requests and perform additional functions is considered a filter driver. We already know that the antivirus driver is a filter driver. Other care drivers include disk quota management, disk mirroring, and backup agents. I've only listed a few here.

Although installing multiple filter drivers is not a problem in itself, the situation changes when these drivers recursively call each other and thus exhaust the limited kernel stack space. According to the computer architecture (x86=12 KB, x64=24 KB), the kernel stack space used by all device drivers is limited. When the kernel stack space is exhausted, a Stop 0x7F bugcheck will cause the system to crash. Like the description of hundreds of Microsoft documents.

There is no way to provide additional kernel stack space to accommodate more care drivers. The only option is to identify these filter drivers, disable or uninstall those that are not needed. there is a built-in tools in Windows Server operating system called fLTMC (filter Manager control program), which lets you identify the installed filter drivers

Figure II:. fLTMC tool

As you can see, there are many reasons why Windows Server crashes. But most server downtimes are caused by the above reasons. You can solve these problems in two ways. They are upgrading Windows. Update the third-party drivers and limit the number of unused filter drivers while the operating system or update related hot fixes.