How to Troubleshoot STOP Error Messages After Enabling Advanced Power Management (237673)



The information in this article applies to:

  • Microsoft Windows 2000 Professional

This article was previously published under Q237673

SUMMARY

If your computer stops responding (hangs) or if you receive a STOP error message, Advanced Power Management (APM) BIOS may be the cause of this behavior in the following situations:
  • When an APM operation was in progress (for example, shutting down, going into standby, or resuming).
  • When a timeout on an idle computer occurred.

MORE INFORMATION

Use the following steps to determine if the behavior occurs because of APM:
  1. Disable APM (on the APM tab of the Power Options tool in Control Panel). If this action does not resolve the behavior, continue to the next step.
  2. Disable APM in the BIOS.
If you disable APM in both Windows 2000 and in the BIOS but your computer still hangs or displays a STOP error message, the issue is probably not related to APM and you should debug/troubleshoot the behavior like any other issue.

NOTE: If the computer you are troubleshooting is a desktop computer and performing the previous steps resolves the issue, the behavior most likely occurred because of APM BIOS that was not fully compliant. Desktop computers are not part of the mission for Windows 2000 APM support. If the computer you are troubleshooting is a laptop, more debugging/troubleshooting is required by the Original Equipment Manufacturer (OEM).

If a debugger is available during bugcheck or when the STOP error message occurs, use the following troubleshooting steps:
  1. Use the !drivers command and make sure that Ntapm.sys is running. If it is not, you are not running APM (even if it appears to be enabled).

    NOTE: If Apmbatt.sys is running and Ntapm.sys is not, your computer may be in an unstable state. After you determine this to be the case, run Apmstat.exe and view the results. For additional information about running Apmstat.exe, click the article number below to view the article in the Microsoft Knowledge Base:

    242495 Troubleshooting APM issues in Windows 2000 using Apmstat.exe

  2. If you have a debugger attached, type the following command:

    dd nt!kiinbioscall L 1

    The output you receive looks similar to the following example:
    kd> dd nt!kiinbioscall l 1
    8046da80  00000000
    						
    • If the result is not 0 (00000000 as shown in the previous example), the computer was in a call to the BIOS when you broke in (or the bugcheck/STOP error message occurred).
    • If KiInBiosCall != 0, the computer failed in the BIOS (most likely the APM BIOS if the bugcheck is associated with an idle timeout, suspend attempt, or a shut down operation).

      At this point, the behavior is clearly an APM BIOS issue that requires further debugging from the OEM. Most issues that are resolved by disabling APM support in Windows 2000 (as well as in the BIOS) are BIOS-related issues that are not supported by Microsoft and require further investigation by the OEM.
    • A value greater than 1 indicates a serious problem that you should immediately report to development.
    • If the KiInBios value is 0, the problem is not in the APM BIOS itself, and further debugging is required.
  3. To find out what the system was doing when it called the BIOS and caused it to fail, type the following command in the debugger:

    dd nt!kibiosframe L 1

    You can use this command to find and dump the arguments to the BIOS call, as shown in the following example:
    kd> dd nt!kibiosframe L 1
    804716c0  00000000
    kd> !trap 804716c0
    eax=f2c7faa0 ebx=f2c7faa0 ecx=00000000 edx=00000000 esi=f2c94f40 edi=0000530b
    eip=00000000 esp=80471734 ebp=f2c7fd70 iopl=0         nv up di pl nz na pe nc
    vip=0    vif=0
    cs=0008  ss=0010  ds=0000  es=0000  fs=0030  gs=0000             efl=00000000
    ErrCode = 00000000
    00000000 ???????????????
    
    ebx has the actual context record of the call
    kd> !cxr f2c7faa0
    						
The !cxr command dumps a context record, which reveals what was passed to the BIOS. A Windows 2000 kernel developer can then usually find which BIOS caller made the call, and what it was trying to accomplish.

NOTE: You cannot just take a stack trace because of APM BIOS or other BIOS-related problems, as they often destroy the stack.

Modification Type:MajorLast Reviewed:11/5/2003
Keywords:kbenv kbhowto KB237673