中国移动网站控件引发的蓝屏问题分析

本周四(2月23日)，我接到了我们同事的一个奇怪的蓝屏case，据他回忆，他最近没有安装任何软件和驱动，也没有更改计算机的硬件配置，除了Windows后台进行的自动更新之外，他实在想不起来到底对计算机有什么额外的改变。可是突然，就从前一天23日周三晚上起，他的计算机就开始蓝屏，重启之后，进系统之前就会蓝屏，或者进了系统用不到一会儿也会蓝屏。因此，他怀疑是硬件(如内存)故障导致的，或者是 Windows Update 导致的问题。

照说，例如内存条松动的这种突发硬件故障的确有可能引发蓝屏，但是由于 Windows Update 推送的补丁缺陷导致的蓝屏可实属少见，在排查蓝屏问题时，我们一般应该遵从默认信任微软自身组件的原则。

据了解，他的蓝屏一般有几个随机的错误代码，查询 Debugging Help 之后，得到的解释如下：

蓝屏代码 (Bug Check) 关键参数 (Parameter) 说明
PFN_LIST_CORRUPT (0x4E)   This is typically caused by a driver passing a bad memory descriptor list. For example, the driver might have called MmUnlockPages twice with the same list. Stack trace examination is needed.
MEMORY_MANAGEMENT (0x1A) P1: 0x41287 Internal memory management structures are corrupted. To further investigate the cause, a kernel memory dump file is needed.
NTFS_FILE_SYSTEM (0x24)   One possible cause of this bug check is disk corruption. Corruption in the NTFS file system or bad blocks (sectors) on the hard disk can induce this error. Corrupted SCSI and IDE drivers can also adversely affect the system's ability to read and write to disk, thus causing the error. Another possible cause is depletion of nonpaged pool memory. If the nonpaged pool memory is completely depleted, this error can stop the system. However, during the indexing process, if the amount of available nonpaged pool memory is very low, another kernel-mode driver requiring nonpaged pool memory can also trigger this error.
SYSTEM_SERVICE_EXCEPTION (0x3B)   This error has been linked to excessive paged pool usage and may occur due to user-mode graphics drivers crossing over and passing bad data to the kernel code.
SYSTEM_THREAD_EXCEPTION
_NOT_HANDLED_M (1000007e)		   This indicates that a system thread generated an exception which the error handler did not catch.

在以上错误中，前两种出现的频率最高。如果您百度一下以上错误，已经有足够的理由开始拆下内存条，擦拭金手指了。但是我个人认为，这一定不是一个硬件产生的错误。在我看来，这样的错误看似随机，其实应该有一种共性的可能性——系统中存在一个写的很烂的驱动。为什么这么讲呢，我们可以从查到的描述中看见"bad""depletion""nonpaged pool"出现的频率很高;另外值得注意的是，对于0x24 NTFS文件系统的 bug check，在很多时候容易产生磁盘损坏的误导，殊不知，它还有一种可能就是非换页池耗尽，如上表中我加粗了的部分。

对于如此随机的错误，我们往往是无法通过分析栈去找到凶手的。例如，我在这里给出一个栈的示例：

 
 
 
 
    
  
  
  
  
  1. MEMORY_MANAGEMENT (1a) 
    2. 
  
  
  
  
  2. # Any other values for parameter 1 must be individually examined. 
    3. 
  
  
  
  
  3. Arguments: 
    4. 
  
  
  
  
  4. Arg1: 0000000000041287, The subtype of the bugcheck. 
    5. 
  
  
  
  
  5. Arg2: 0000000000000030 
    6. 
  
  
  
  
  6. Arg3: 0000000000000000 
    7. 
  
  
  
  
  7. Arg4: 0000000000000000 
    8. 
  
  
  
  
  8. 
  
  
  
  
  9. Debugging Details: 
    10. 
  
  
  
  
  10. ------------------ 
    11. 
  
  
  
  
  11. 
  
  
  
  
  12. BUGCHECK_STR: 0x1a_41287 
    13. 
  
  
  
  
  13. DEFAULT_BUCKET_ID: VISTA_DRIVER_FAULT 
    14. 
  
  
  
  
  14. PROCESS_NAME: WmiPrvSE.exe 
    15. 
  
  
  
  
  15. CURRENT_IRQL: 0 
    16. 
  
  
  
  
  16. TRAP_FRAME: fffff88007e6d6e0 -- (.trap 0xfffff88007e6d6e0) 
    17. 
  
  
  
  
  17. NOTE: The trap frame does not contain all registers. 
    18. 
  
  
  
  
  18. Some register values may be zeroed or incorrect. 
    19. 
  
  
  
  
  19. 
  
  
  
  
  20. STACK_TEXT:  
    21. 
  
  
  
  
  21. fffff880`07e6d578 fffff800`02c62d7e : 00000000`0000001a 00000000`00041287 00000000`00000030 00000000`00000000 : nt!KeBugCheckEx 
    22. 
  
  
  
  
  22. fffff880`07e6d580 fffff800`02ccdd6e : 00000000`00000000 00000000`00000030 00000000`00000000 00000000`fffffa80 : nt! ?? ::FNODOBFM::`string'+0x46485 
    23. 
  
  
  
  
  23. fffff880`07e6d6e0 fffff800`02dadbc5 : 00000000`000af94a 00000000`00000000 ffffffff`ffffffff 00000000`01464000 : nt!KiPageFault+0x16e 
    24. 
  
  
  
  
  24. fffff880`07e6d870 fffff800`02d426b0 : fffffa80`098d5058 fffff6fd`4004c6a8 fffff800`02f055c0 fffff880`07e6db11 : nt!MiResolvePageFileFault+0x1115 
    25. 
  
  
  
  
  25. fffff880`07e6d9b0 fffff800`02cdea07 : 00000000`00000000 00000000`01440004 00000000`0240f3c4 fffff800`00000000 : nt! ?? ::FNODOBFM::`string'+0x399d4 
    26. 
  
  
  
  
  26. fffff880`07e6dac0 fffff800`02ccdd6e : 00000000`00000001 00000000`01440004 00000000`023ae701 00000000`00000460 : nt!MmAccessFault+0x1e47 
    27. 
  
  
  
  
  27. fffff880`07e6dc20 00000000`76b87222 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KiPageFault+0x16e 
    28. 
  
  
  
  
  28. 00000000`0240f394 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : 0x76b87222
    29.

可以看见，除了ntkrnlmp.exe里面的函数，最前面发生的0x76b87222根本无法解析出来。dds 命令也是不能够解析出具体名称的。

那么，究竟该怎么样才能找到问题的元凶呢?

其实，将随机的蓝屏错误通过启用特殊池来转化为明显的错误是比较好的选择。对于特殊池(special pool)的概念，我并不是第一次介绍了，关于这个神奇的特殊内存区域的调试方法，请参见我早些时候的文章《启用特殊池解读 0x000000c5 蓝屏》，或者其英文版《Enable "Special Pool" to Interpret 0x000000c5 Blue Screen》。

从安全模式启动系统，启动 verifier，配置启用 special pool. 当然，安全模式下，可能引发问题的驱动也许并未加载，因此，我们最好选择"从一个列表选择驱动程序名"，然后继续选择"将目前没有加载的驱动程序添加到列表中…"，在弹出的选择文件对话框中，浏览 %systemroot%\system32\derivers , 然后增加"版权"和"产品名称"两列文件属性，并按照它们排序。选择所有不是微软的程序驱动，或者选择没有数字签名/版权和产品信息不完整的看似不专业的驱动，添加进来选中应用特殊池即可。

这里需要说明一下，其实特殊池的设置保存在注册表之中，具体是在内存管理器的分支里：

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

它靠 DWord 值 VerifyDriverLevel 和 String 值 VerifyDrivers 控制。有兴趣大家可以去窥探一下 J

启用特殊池之后，我们就重启计算机，正常进入系统尝试 repro 这个问题。没一会儿，还没登录果然就又蓝了。这回直接进入安全模式，获得内存转储文件进行分析：

首先我们可以看见，特殊池生效了，而且成功进行了内存池分配：

 
 
 
 
    
  
  
  
  
  1. 4: kd> !verifier 
    2. 
  
  
  
  
  2. 
  
  
  
  
  3. Verify Level 1 ... enabled options are: 
    4. 
  
  
  
  
  4.     Special pool 
    5. 
  
  
  
  
  5. 
  
  
  
  
  6. Summary of All Verifier Statistics 
    7. 
  
  
  
  
  7. 
  
  
  
  
  8. RaiseIrqls 0x0 
    9. 
  
  
  
  
  9. AcquireSpinLocks 0x0 
    10. 
  
  
  
  
  10. Synch Executions 0x0 
    11. 
  
  
  
  
  11. Trims 0x0 
    12. 
  
  
  
  
  12. 
  
  
  
  
  13. Pool Allocations Attempted 0x2 
    14. 
  
  
  
  
  14. Pool Allocations Succeeded 0x2 
    15. 
  
  
  
  
  15. Pool Allocations Succeeded SpecialPool 0x2 
    16. 
  
  
  
  
  16. Pool Allocations With NO TAG 0x0 
    17. 
  
  
  
  
  17. Pool Allocations Failed 0x0 
    18. 
  
  
  
  
  18. Resource Allocations Failed Deliberately 0x0 
    19. 
  
  
  
  
  19. 
  
  
  
  
  20. Current paged pool allocations 0x0 for 00000000 bytes 
    21. 
  
  
  
  
  21. Peak paged pool allocations 0x0 for 00000000 bytes 
    22. 
  
  
  
  
  22. Current nonpaged pool allocations 0x0 for 00000000 bytes 
    23. 
  
  
  
  
  23. Peak nonpaged pool allocations 0x0 for 00000000 bytes 
    24. 
  
  
  
  
  24.  
    25.

然后，我们可以直接看到问题驱动究竟是谁了：

 
 
 
 
    
  
  
  
  
  1. DRIVER_VERIFIER_DETECTED_VIOLATION (c4) 
    2. 
  
  
  
  
  2. A device driver attempting to corrupt the system has been caught. This is 
    3. 
  
  
  
  
  3. because the driver was specified in the registry as being suspect (by the 
    4. 
  
  
  
  
  4. administrator) and the kernel has enabled substantial checking of this driver. 
    5. 
  
  
  
  
  5. If the driver attempts to corrupt the system, bugchecks 0xC4, 0xC1 and 0xA will 
    6. 
  
  
  
  
  6. be among the most commonly seen crashes. 
    7. 
  
  
  
  
  7. Arguments: 
    8. 
  
  
  
  
  8. Arg1: 00000000000000b2, MmMapLockedPages called on an MDL having incorrect flags. 
    9. 
  
  
  
  
  9.     For example, calling MmMapLockedPages for an MDL 
    10. 
  
  
  
  
  10.     that is already mapped to a system address is incorrect. 
    11. 
  
  
  
  
  11. Arg2: fffffa800a4e71b0, MDL address. 
    12. 
  
  
  
  
  12. Arg3: 0000000000000005, MDL flags. 
    13. 
  
  
  
  
  13. Arg4: 0000000000000005, Incorrect MDL flags. 
    14. 
  
  
  
  
  14. 
  
  
  
  
  15. Debugging Details: 
    16. 
  
  
  
  
  16. ------------------ 
    17. 
  
  
  
  
  17. BUGCHECK_STR: 0xc4_b2 
    18. 
  
  
  
  
  18. DEFAULT_BUCKET_ID: VISTA_DRIVER_FAULT 
    19. 
  
  
  
  
  19. PROCESS_NAME: System 
    20. 
  
  
  
  
  20. CURRENT_IRQL: 0 
    21. 
  
  
  
  
  21. LAST_CONTROL_TRANSFER: from fffff8000311f3dc to fffff80002c95c40 
    22. 
  
  
  
  
  22. STACK_TEXT:  
    23. 
  
  
  
  
  23. fffff880`033697e8 fffff800`0311f3dc : 00000000`000000c4 00000000`000000b2 fffffa80`0a4e71b0 00000000`00000005 : nt!KeBugCheckEx 
    24. 
  
  
  
  
  24. fffff880`033697f0 fffff800`0311ffb3 : fffff880`05926f60 fffff880`05926f60 fffffa80`069ce700 fffff800`0312e09a : nt!VerifierBugCheckIfAppropriate+0x3c 
    25. 
  
  
  
  
  25. fffff880`03369830 fffff800`031327bb : fffffa80`0a4e71b0 fffffa80`09b69000 fffffa80`0a4e71b0 fffff880`05926f60 : nt!ViMmMapLockedPagesSanityChecks+0xa3 
    26. 
  
  
  
  
  26. fffff880`03369870 fffff880`06220009 : fffffa80`0a4e72c0 ffffffff`8000069c fffffa80`0a4e72c0 00000000`00000000 : nt!VerifierMmMapLockedPages+0x1b 
    27. 
  
  
  
  
  27. fffff880`033698b0 fffff880`0624c93a : fffff880`03369970 fffff880`05926f60 fffffa80`00000032 00000000`0000001c : PassGuard_x64!distorm_version+0x6809 
    28. 
  
  
  
  
  28. fffff880`033698f0 fffff880`03369970 : fffff880`05926f60 fffffa80`00000032 00000000`0000001c fffffa80`06768f30 : PassGuard_x64!distorm_version+0x3313a 
    29. 
  
  
  
  
  29. fffff880`033698f8 fffff880`05926f5f : fffffa80`00000032 00000000`0000001c fffffa80`06768f30 00000000`00000200 : 0xfffff880`03369970 
    30. 
  
  
  
  
  30. fffff880`03369900 fffffa80`00000032 : 00000000`0000001c fffffa80`06768f30 00000000`00000200 00000000`00000000 : usbhub!UsbhSyncSendCommand+0x327 
    31. 
  
  
  
  
  31. fffff880`03369908 00000000`0000001c : fffffa80`06768f30 00000000`00000200 00000000`00000000 fffff880`06232040 : 0xfffffa80`00000032 
    32. 
  
  
  
  
  32. fffff880`03369910 fffffa80`06768f30 : 00000000`00000200 00000000`00000000 fffff880`06232040 00000000`001e001c : 0x1c 
    33. 
  
  
  
  
  33. fffff880`03369918 00000000`00000200 : 00000000`00000000 fffff880`06232040 00000000`001e001c fffff880`062563f8 : 0xfffffa80`06768f30 
    34. 
  
  
  
  
  34. fffff880`03369920 00000000`00000000 : fffff880`06232040 00000000`001e001c fffff880`062563f8 00000000`00220020 : 0x200 
    35. 
  
  
  
  
  35. 
  
  
  
  
  36. STACK_COMMAND: kb 
    37. 
  
  
  
  
  37. FOLLOWUP_IP:  
    38. 
  
  
  
  
  38. PassGuard_x64!distorm_version+6809 
    39. 
  
  
  
  
  39. fffff880`06220009 4889442428 mov qword ptr [rsp+28h],rax 
    40. 
  
  
  
  
  40. SYMBOL_STACK_INDEX: 4 
    41. 
  
  
  
  
  41. SYMBOL_NAME: PassGuard_x64!distorm_version+6809 
    42. 
  
  
  
  
  42. FOLLOWUP_NAME: MachineOwner 
    43. 
  
  
  
  
  43. MODULE_NAME: PassGuard_x64 
    44. 
  
  
  
  
  44. IMAGE_NAME: PassGuard_x64.sys 
    45. 
  
  
  
  
  45. DEBUG_FLR_IMAGE_TIMESTAMP: 4e2fb9f4 
    46. 
  
  
  
  
  46. FAILURE_BUCKET_ID: X64_0xc4_b2_VRF_PassGuard_x64!distorm_version+6809 
    47. 
  
  
  
  
  47. BUCKET_ID: X64_0xc4_b2_VRF_PassGuard_x64!distorm_version+6809 
    48. 
  
  
  
  
  48. Followup: MachineOwner 
    49. 
  
  
  
  
  49. --------- 
    50. 
  
  
  
  
  50. 
  
  
  
  
  51. 4: kd> lmvm PassGuard_x64 
    52. 
  
  
  
  
  52. start end module name 
    53. 
  
  
  
  
  53. fffff880`06218000 fffff880`06261000 PassGuard_x64 (export symbols) PassGuard_x64.sys 
    54. 
  
  
  
  
  54. Loaded symbol image file: PassGuard_x64.sys 
    55. 
  
  
  
  
  55. Image path: \??\C:\windows\system32\drivers\PassGuard_x64.sys 
    56. 
  
  
  
  
  56. Image name: PassGuard_x64.sys 
    57. 
  
  
  
  
  57. Timestamp: Wed Jul 27 15:10:44 2011 (4E2FB9F4) 
    58. 
  
  
  
  
  58. CheckSum: 0004A5F0 
    59. 
  
  
  
  
  59. ImageSize: 00049000 
    60. 
  
  
  
  
  60. File version: 1.0.0.6 
    61. 
  
  
  
  
  61. Product version: 1.0.0.6 
    62. 
  
  
  
  
  62. File flags: 0 (Mask 17) 
    63. 
  
  
  
  
  63. File OS: 4 Unknown Win32 
    64. 
  
  
  
  
  64. File type: 1.0 App 
    65. 
  
  
  
  
  65. File date: 00000000.00000000 
    66. 
  
  
  
  
  66. Translations: 0804.04b0 
    67. 
  
  
  
  
  67. ProductName: SysEnter Application 
    68. 
  
  
  
  
  68. InternalName: SysEnter 
    69. 
  
  
  
  
  69. OriginalFilename: SysEnter.exe 
    70. 
  
  
  
  
  70. ProductVersion: 1, 0, 0, 6 
    71. 
  
  
  
  
  71. FileVersion: 1, 0, 0, 6 
    72. 
  
  
  
  
  72. FileDescription: SysEnter Application 
    73. 
  
  
  
  
  73. LegalCopyright: Copyright (C) 2011
    74.

好了，知道了这个叫 PassGuard_x64.sys 的驱动是罪魁祸首之后，那我们就该移除它的启动加载了。直接在安全模式打开注册表编辑器，删除HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services 下面的 PassGuard 整个键，当然，你还需要找到 ControlSet001 / 002 下面的同样的键删除。这里，我顺便把这个 PassGuard 键的内容展示出来：

 
 
 
 
    
  
  
  
  
  1. [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\PassGuard] 
    2. 
  
  
  
  
  2. "Type"=dword:00000001 
    3. 
  
  
  
  
  3. "Start"=dword:00000002 
    4. 
  
  
  
  
  4. "ErrorControl"=dword:00000001 
    5. 
  
  
  
  
  5. "ImagePath"=hex(2):5c,00,3f,00,3f,00,5c,00,43,00,3a,00,5c,00,77,00,69,00,6e,00,\ 
    6. 
  
  
  
  
  6. 64,00,6f,00,77,00,73,00,5c,00,73,00,79,00,73,00,74,00,65,00,6d,00,33,00,32,\ 
    7. 
  
  
  
  
  7. 00,5c,00,64,00,72,00,69,00,76,00,65,00,72,00,73,00,5c,00,50,00,61,00,73,00,\ 
    8. 
  
  
  
  
  8. 73,00,47,00,75,00,61,00,72,00,64,00,5f,00,78,00,36,00,34,00,2e,00,73,00,79,\ 
    9. 
  
  
  
  
  9. 00,73,00,00,00 
    10. 
  
  
  
  
  10. "DisplayName"="PassGuard" 
    11. 
  
  
  
  
  11. "WOW64"=dword:00000001 
    12. 
  
  
  
  
  12. 
  
  
  
  
  13. [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\PassGuard\Enum] 
    14. 
  
  
  
  
  14. "0"="Root\\LEGACY_PASSGUARD\\0000" 
    15. 
  
  
  
  
  15. "Count"=dword:00000001 
    16. 
  
  
  
  
  16. "NextInstance"=dword:00000001
    17.

删除这个键，如果没有其他的多重问题，那么系统就能正常运行了。在重启进入正常模式之前，记得删除 verifier 中的特殊池配置。

为了进一步删除该驱动所关联的程序或者其他文件(如果有的话)，我请这位同事仔细回忆这是什么。于是，我叫他回忆一下任何可能的情况，例如IE插件的变化、某些程序里面的捆绑、恶意程序等等。结果，他想起周三下午有去中国移动的 10086.cn 充值话费，安装了一个安全控件。

我们打开IE加载项管理器，选择所有加载项，果然发现了这一个：

还好不是恶意软件，而且可以通过下面的 remove 按钮删除关联的控件文件。好了，不多说了，看看中国移动为64位操作系统写的驱动有多烂你就明白了。

从这个案例中，我想我们看到的不仅仅是特殊池的使用方法和排错思路，而且还应看到现在很多信息服务公司所面临的一个问题，自己的产品的驱动外包出去，而且承包开发驱动的公司没有足够的驱动撰写经验和规范，或者没有经过测试就投入使用，受损的不仅是客户，更是这个服务公司自身的品牌。这样的例子太多了，延伸起来不仅有 badly written driver, 还有 badly written software, badly written website… 铁道部12306网站说多了就没意思了，说句实话，现在中国联通在营业厅推行的银行卡缴费机我真是不敢用。想想要把银行卡插进联通外包商开发的机器中去，还要输入银行卡密码我就觉得胆战心惊.

原文：http://www.cnblogs.com/mvperic/archive/2012/02/26/2369225.html

当前名称：中国移动网站控件引发的蓝屏问题分析
文章转载：http://www.shufengxianlan.com/qtweb/news47/449847.html

网站建设、网络推广公司-创新互联，是专注品牌与效果的网站制作，网络营销seo公司；服务项目有等

广告

声明：本网站发布的内容（图片、视频和文字）以用户投稿、用户转载内容为主，如果涉及侵权请尽快告知，我们将会在第一时间删除。文章观点不代表本网站立场，如需处理请联系客服。电话：028-86922220；邮箱：631063699@qq.com。内容未经允许不得转载，或转载时需注明来源： 创新互联

猜你还喜欢下面的内容

做网站知识

分类信息网站

全网营销推广　　 　鑫友邦火锅桌　　 　东电技改　　 　企业网站制作　　 　网站设计　　 　彭州网站建设　　 　眉山电信机房　　 　东电技服　　 　马边网站建设　　 　产品包装设计　　 　力比特工程　　 　软文发稿　　 　云服务器　　 　成都集团网站建设　　 　内江做网站　　 　时嘉做网站　　 　成都名片印刷厂　　 　商城网站　　 　成都主机托管　　 　成都400电话