Video Driver not Loading on Windows XP

 

Hi all, Anshuman here with an issue I ran into recently where a customer’s Windows XP machine was loading the standard VGA driver and gave a maximum display resolution of 640×480. The event log showed the following event after boot:

 

Event Type: Information

Event Source: Application Popup

Event Category: None

Event ID: 26

Date:  12/3/2009

Time:  6:38:49 AM

User:  N/A

Computer: Computer1

Description:

Application popup:  : \SystemRoot\System32\VidDisplay.dll failed to load

0000: 00000000 006c0002 00000000 4000001a

0010: c0000017 c000026c 00000000 00000000

0020: 00000000 00000000

 

So we have an information popup stating that a specific binary failed to load. The binary in this case belongs to a third-party, but the issue is not one of the driver crashing or anything. So why is this not loading? Extracting the DWORD data (highlighted above in red) and using the Err.exe utility to translate the error codes, we get the following:

 

>err c0000017

# for hex 0xc0000017 / decimal -1073741801 :

  STATUS_NO_MEMORY

# {Not Enough Quota}

# Not enough virtual memory or paging file quota is available

# to complete the specified operation.

# 1 matches found for "c0000017"

 

>err c000026c

# for hex 0xc000026c / decimal -1073741204 :

  STATUS_DRIVER_UNABLE_TO_LOAD

# {Unable to Load Device Driver}

# %hs device driver could not be loaded.

# Error Status was 0x%x

# 1 matches found for "c000026c"

 

So the reason for STATUS_DRIVER_UNABLE_TO_LOAD is STATUS_NO_MEMORY. Turns out the reason for the memory depletion was that the customer was running the Windows XP box with the /3GB switch set in the Boot.ini. As you may recall from our previous post, using /3GB has a drastic effect on the amount of memory available to the system kernel, which is of course where drivers have to load. Knowing now what the root issue is, a simple search led to the following kb article:

 

319043 Driver may not be loaded with the /3GB switch

 

As we were already on Service Pack 3 for Windows XP, the hotfix was not necessary so we tried the values of /USERVA=2800 and even /USERVA=2500, but the problem still remained. Drawing a blank here, I thought of checking the following registry key for any specific value that may be different than on a clean system:

 

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management

 

While all values looked to be the default, I found the following additional entry under the key:

 

"SessionImageSize"=dword:00000010  (hex 10 is the same as decimal 16)

 

SessionImageSize is a registry key related to the session image space, and is a section of Kernel Address Space where display drivers load. The default for this is 8 MB.  This same information can be found by using the debugger:

 

0: kd> dd nt!MmSessionImageSize l1

 

When I did this on the customer’s machine, I got the following:

 

e0c2db20 00800000    <—- with /3GB

80561b20 0x1000000   <—- without /3GB

 

The first value equates to 8 (8 MB) and the second is 16 (16 MB) since 0x10 hex is 16 in decimal.

Deleting this value from the registry (it does not exist by default) and booting up without the /3GB switch, we were still able to reproduce the issue. So essentially the issue seemed to be that the size of the display driver binaries needed more than 8MB of SessionImageSize available by default. In order to achieve this the driver set the value of SessionImageSize in the registry to 16MB.

However with the /3GB switch set, the rules of the game changed. Since the kernel has only 1 GB of virtual address space to work with, the value is hardcoded at 8 MB, and any custom setting is ignored. So, even though the registry value was set to 16 MB, the actual amount as shown by the debugger was 8 MB.

Solution? Well if we need to get these display driver binaries loaded, boot without the /3GB switch, where the value of SessionImageSize can be set to a higher value. Or you could install a display driver that does not need more than 8 MB of session space to load. Another option of course would be to go 64-bit, but that is a post for another day 😉

 

Till next time,

Anshuman Gosh


Share this post :