Windows 7 RTM存儲(chǔ)控制器 - 一些小問(wèn)題總結(jié)

一、我的臺(tái)式計(jì)算機(jī)dell inspiron530

我在以前的文章里也摸索過(guò)一些問(wèn)題，這里簡(jiǎn)要的介紹下硬件配置。主板是intel的3系列，南橋只有sata接口，接了一個(gè)硬盤和一個(gè)光驅(qū)。 pci卡上插了一塊silicon image的i680存儲(chǔ)控制器，以兼容我老式機(jī)器的一塊硬盤和一個(gè)光驅(qū)。

問(wèn)題1：安裝時(shí)不能正常加載silicon image存儲(chǔ)控制器的驅(qū)動(dòng)。

這 個(gè)問(wèn)題以前的文章里也提及過(guò)，安裝時(shí)驅(qū)動(dòng)不能加載，或者說(shuō)是在加載畫面卡住。即使過(guò)了很長(zhǎng)時(shí)間，加載畫面過(guò)去了，此時(shí)又回到安裝時(shí)的硬盤選項(xiàng)，驅(qū)動(dòng)任然沒(méi) 有被安裝。安裝系統(tǒng)時(shí)不去安裝這個(gè)驅(qū)動(dòng)，直接安裝系統(tǒng)（安裝在主板集成的那個(gè)控制器下掛載的硬盤上），等安裝好了系統(tǒng)，操作系統(tǒng)會(huì)自動(dòng)加載驅(qū)動(dòng)，這個(gè)驅(qū)動(dòng) 還和我用介質(zhì)安裝時(shí)手動(dòng)加載的驅(qū)動(dòng)還是一樣。

問(wèn)題2：自動(dòng)安裝存儲(chǔ)控制器之后，硬盤和光驅(qū)被計(jì)算機(jī)管理工具識(shí)別，但是我的電腦里不能被加載使用，重啟一下計(jì)算機(jī)，所有的硬盤和光驅(qū)才可以正常使用。

問(wèn)題3：安裝存儲(chǔ)控制器驅(qū)動(dòng)后的第一次關(guān)機(jī)不正常。

操 作系統(tǒng)剛安裝好的時(shí)候，會(huì)自動(dòng)安裝一些硬件和驅(qū)動(dòng)，這時(shí)出現(xiàn)了問(wèn)題2。經(jīng)過(guò)我實(shí)踐證明，只要重啟下，以后再次使用，問(wèn)題2就不存在了。但是第一次系統(tǒng)重啟 時(shí)又會(huì)出現(xiàn)新的問(wèn)題，就是不能正常關(guān)機(jī)。屏幕顯示正在關(guān)機(jī)，然后就卡住了。過(guò)了正常的關(guān)機(jī)時(shí)間范圍，看看硬盤燈基本也不亮了，電源就是不熄火，屏幕卡在正 在關(guān)機(jī)畫面。

在7260版本時(shí)，我過(guò)了個(gè)十多分鐘就直接強(qiáng)制重啟了，之后的系統(tǒng)一切正常，什么問(wèn)題都沒(méi)有了。

這次是裝RTM版，由于已經(jīng)有了前一次這樣的情況。我直接搬來(lái)本本，看著它，看它到底能發(fā)生什么。一直等待了大約半個(gè)小時(shí)，藍(lán)屏了哈。這就意味著我可以去看看dump文件了。

DRIVER_POWER_STATE_FAILURE (9f)
A driver is causing an inconsistent power state.
Arguments:
Arg1: 00000004, The power transition timed out waiting to synchronize with the Pnp
    subsystem.
Arg2: 00000258, Timeout in seconds.
Arg3: 84d7ad48, The thread currently holding on to the Pnp lock.
Arg4: 8275db24

上面的報(bào)錯(cuò)信息是說(shuō)一個(gè)驅(qū)動(dòng)導(dǎo)致錯(cuò)誤的電源狀態(tài)，電源傳輸?shù)却�即插即用設(shè)備同步超時(shí)。

FOLLOWUP_IP:
cdrom!DeviceSendPowerProcessRequest+15b
8b7f4916 84c0            test    al,al

SYMBOL_STACK_INDEX:  8

SYMBOL_NAME:  cdrom!DeviceSendPowerProcessRequest+15b

FOLLOWUP_NAME:  MachineOwner

MODULE_NAME: cdrom

IMAGE_NAME:  cdrom.sys

DEBUG_FLR_IMAGE_TIMESTAMP:  4a5bbf1c

FAILURE_BUCKET_ID:  0x9F_cdrom!DeviceSendPowerProcessRequest+15b

BUCKET_ID:  0x9F_cdrom!DeviceSendPowerProcessRequest+15b

上 面的信息給出了錯(cuò)誤指令和所在模塊以及偏移地址。上面橙色mark的地方就是我猜測(cè)的錯(cuò)誤的地方了哈：test    al,al。test指令是條測(cè)試指令，要根據(jù)結(jié)果影響FR（標(biāo)志寄存器）的。test    al,al，自己和自己比較，這個(gè)結(jié)果肯定是一個(gè)一定的結(jié)果，如果后面的指令根據(jù)test    al,al所影響的標(biāo)志寄存器的位來(lái)判斷轉(zhuǎn)跳什么的，這個(gè)很可能造成死循環(huán)哦，死循環(huán)就可能導(dǎo)致其他進(jìn)程超時(shí)。我猜這個(gè)算是微軟coder的一個(gè)筆誤吧！

0: kd> lmvm cdrom
start    end        module name
8b7df000 8b7fe000   cdrom      (pdb symbols)          d:\symbolslocal\cdrom.pdb\45095501C39640C5BEEACE8E677232CC2\cdrom.pdb
    Loaded symbol image file: cdrom.sys
    Mapped memory image file: D:\symbolslocal\cdrom.sys\4A5BBF1C1f000\cdrom.sys
    Image path: \SystemRoot\system32\DRIVERS\cdrom.sys
    Image name: cdrom.sys
    Timestamp:        Tue Jul 14 07:11:24 2009 (4A5BBF1C)
    CheckSum:         00029646
    ImageSize:        0001F000
    File version:     6.1.7600.16385
    Product version:  6.1.7600.16385
    File flags:       0 (Mask 3F)
    File OS:          40004 NT Win32
    File type:        3.7 Driver
    File date:        00000000.00000000
    Translations:     0000.04b0
    CompanyName:      Microsoft Corporation
    ProductName:      Microsoft® Windows® Operating System
    InternalName:     cdrom.sys
    OriginalFilename: cdrom.sys
    ProductVersion:   6.1.7600.16385
    FileVersion:      6.1.7600.16385 (win7_rtm.090713-1255)
    FileDescription:  SCSI CD-ROM Driver
    LegalCopyright:   © Microsoft Corporation. All rights reserved.

這 里給出的就是錯(cuò)誤的cdrom模塊的信息，這個(gè)是微軟提供的驅(qū)動(dòng)哦。FileDescription:  SCSI CD-ROM Driver，這個(gè)是一個(gè)scsi類型的驅(qū)動(dòng)，和我最前面給出的硬件示意圖不同哈。其實(shí)這個(gè)PCI擴(kuò)展的存儲(chǔ)控制器是把IDE設(shè)備模擬成scsi設(shè)備的。 這個(gè)也就解釋了為什么這個(gè)設(shè)備會(huì)被定義為pnp設(shè)備了，IDE不可以熱插拔，sata和scsi是可以熱插拔的，所以后兩者應(yīng)該也算pnp吧。

Debugging Details:
------------------

DRVPOWERSTATE_SUBCODE:  4

FAULTING_THREAD:  84d7ad48

CUSTOMER_CRASH_COUNT:  1

DEFAULT_BUCKET_ID:  VISTA_DRIVER_FAULT

BUGCHECK_STR:  0x9F

PROCESS_NAME:  System

CURRENT_IRQL:  2

LAST_CONTROL_TRANSFER:  from 826a5b15 to 8269e966

STACK_TEXT: 
8d5136c0 826a5b15 84d7ad48 00000000 807c2120 nt!KiSwapContext+0x26
8d5136f8 826a4403 84d7ae08 84d7ad48 8d5137e4 nt!KiSwapThread+0x266
8d513720 8269e2cf 84d7ad48 84d7ae08 00000000 nt!KiCommitThreadWait+0x1df
8d51379c 8b21d0a5 8d5137e4 00000000 00000000 nt!KeWaitForSingleObject+0x393
8d5137bc 8b21d5de 00000000 85197010 8d513814 Wdf01000!FxCREvent::EnterCRAndWait+0x1d
8d5137cc 8b21f4df 00000000 79ea1d58 8d51385c Wdf01000!FxCREvent::EnterCRAndWaitAndLeave+0xe
8d513814 8b22affe 00197010 8d51385c 8d513840 Wdf01000!FxIoTarget::SubmitSync+0x1db
8d513838 8b7f4916 00000020 85197010 8615e2a0 Wdf01000!imp_WdfRequestSend+0x178
8d51387c 8b7f4790 00000004 00000314 86e4d010 cdrom!DeviceSendPowerProcessRequest+0x15b
8d513890 8b25fd5c 792ba660 00000005 00000314 cdrom!DeviceEvtD0Exit+0x83
8d5138b0 8b25ed81 86e4d010 86e4d11c 86e4d010 Wdf01000!FxPkgPnp::PowerGotoD3Stopped+0xc7
8d513938 8b25fbb2 00000314 86e4d11c 86e4d010 Wdf01000!FxPkgPnp::PowerEnterNewState+0x11c
8d51395c 8b2605bb 8d513974 00000008 86e4d010 Wdf01000!FxPkgPnp::PowerProcessEventInner+0x171
8d513980 8b269747 00000001 8d5139b4 8b26967c Wdf01000!FxPkgPnp::PowerProcessEvent+0x15c
8d51398c 8b26967c 86e4d010 86e4d18c 86e4d010 Wdf01000!FxPkgPnp::NotPowerPolOwnerStopping+0x12
8d5139b4 8b2667f5 0000055b 86e4d18c 86e4d010 Wdf01000!FxPkgPnp::NotPowerPolicyOwnerEnterNewState+0x105
8d5139d8 8b267388 00000002 00000008 86e4d010 Wdf01000!FxPkgPnp::PowerPolicyProcessEventInner+0x264
8d5139fc 8b264079 00000001 00000000 8d513a34 Wdf01000!FxPkgPnp::PowerPolicyProcessEvent+0x172
8d513a0c 8b263484 86e4d010 86e4d0b8 86e4d010 Wdf01000!FxPkgPnp::PnpEventStartedStopping+0x11
8d513a34 8b263db2 0000010e 86e4d0b8 86e4d010 Wdf01000!FxPkgPnp::PnpEnterNewState+0x104
8d513a58 8b26447a 8d513a70 00000000 86e4d010 Wdf01000!FxPkgPnp::PnpProcessEventInner+0x149
8d513a7c 8b25b68f 00000200 00000000 85c43828 Wdf01000!FxPkgPnp::PnpProcessEvent+0x13e
8d513aa8 8b25ce02 86e4d010 86d64cc0 86d64cc0 Wdf01000!FxPkgPnp::_PnpRemoveDevice+0x8b
8d513ac8 8b239a3f 86d64cc0 8d513af0 8b239c63 Wdf01000!FxPkgPnp::Dispatch+0x207
8d513ad4 8b239c63 86752ef0 86d64cc0 86d64d9c Wdf01000!FxDevice::Dispatch+0x7f
8d513af0 826734bc 86752ef0 00000000 8d513b8c Wdf01000!FxDevice::DispatchWithLock+0x7b
8d513b08 82813edf 861e1030 868b1c20 861e1030 nt!IofCallDriver+0x63
8d513b38 827eab3d 861e1030 00000000 868b1c20 nt!IopSynchronousCall+0xc2
8d513b90 8264bc3a 861e1030 00000002 b7be0d78 nt!IopRemoveDevice+0xd4
8d513bbc 827ea951 00000015 b7be0d78 00000000 nt!PnpRemoveLockedDeviceNode+0x16c
8d513bd0 827ea8b7 00000002 00000015 00000000 nt!PnpDeleteLockedDeviceNode+0x2d
8d513c04 827ea238 861e1030 b7be0d78 00000002 nt!PnpDeleteLockedDeviceNodes+0x4c
8d513cc4 827ec210 8d513cf4 00000000 c20ba8b8 nt!PnpProcessQueryRemoveAndEject+0x946
8d513cdc 827edd58 00000000 8546c0c0 84d7ad48 nt!PnpProcessTargetDeviceEvent+0x38
8d513d00 826a4f2b 8546c0c0 00000000 84d7ad48 nt!PnpDeviceEventWorker+0x216
8d513d50 8284566d 00000001 a72c37ea 00000000 nt!ExpWorkerThread+0x10d
8d513d90 826f70d9 826a4e1e 00000001 00000000 nt!PspSystemThreadStartup+0x9e
00000000 00000000 00000000 00000000 00000000 nt!KiThreadStartup+0x19

上 面是stack，從上面的函數(shù)名和調(diào)用關(guān)系可以看出調(diào)用關(guān)系和函數(shù)大概功能。先說(shuō)下Wdf01000.sys這個(gè)系統(tǒng)文件，lmvm它一 下，F(xiàn)ileDescription:  Kernel Mode Driver Framework Runtime，這個(gè)是個(gè)內(nèi)核模式下的驅(qū)動(dòng)構(gòu)架運(yùn)行時(shí)庫(kù)。（哎～～要是有這些內(nèi)核函數(shù)的文檔就好了，真想看哈！）

大略的可以看下上面的調(diào)用：關(guān)機(jī)時(shí)，內(nèi)核刪除pnp設(shè)備，通過(guò)調(diào)用Wdf01000，經(jīng)過(guò)Wdf01000的分發(fā)器，調(diào)整pnp的設(shè)備狀態(tài)以及電源狀態(tài)。在橙色標(biāo)記的那個(gè)函數(shù)發(fā)生了錯(cuò)誤，導(dǎo)致之后同步錯(cuò)誤吧。而這里的同步可能就是指設(shè)備狀態(tài)和電源狀態(tài)的同步吧。

關(guān)于電源狀態(tài)：

對(duì)于一些設(shè)備. 例如調(diào)制解調(diào)器 , 硬盤, 光驅(qū)等. 可分為：
D0 - Fully-On 正常工作下.
D1 可節(jié)省較少的功耗，仍然保持ACTIVE的設(shè)備功能較D2要多的多,該狀態(tài)由設(shè)備本身所決定，有些設(shè)備不能進(jìn)入D1 STATE。
D2 某些功能被關(guān)閉. 可省較多的電源. 該狀態(tài)由設(shè)備本身所決定，有些設(shè)備不能進(jìn)入D2 STATE。
D3 - Off 此狀態(tài)下設(shè)備的電源完全被移出， 所以下次電源再一次被供應(yīng)時(shí)需要操作系統(tǒng)重新再對(duì)這個(gè)設(shè)備作一次設(shè)定（此狀態(tài)下設(shè)備不對(duì)地址線進(jìn)行譯碼）該狀態(tài)需要最長(zhǎng)的喚醒時(shí)間，所有的設(shè)備都可以進(jìn)入該狀態(tài)。

在綠色mark的那個(gè)函數(shù)可以看到電源狀態(tài)已經(jīng)被要求進(jìn)入D3狀態(tài)了。應(yīng)該說(shuō)這個(gè)設(shè)備已經(jīng)關(guān)閉了，也就是在后面同步電源狀態(tài)的時(shí)候出問(wèn)題，導(dǎo)致我電腦總是不斷電，而是在關(guān)機(jī)畫面定住了哈。

總的來(lái)說(shuō)，windows7各個(gè)方面的表現(xiàn)還是很搶眼的，雖然上面我遇到了很多問(wèn)題，但是這些問(wèn)題都出在剛安裝系統(tǒng)或者加載設(shè)備驅(qū)動(dòng)。屬于“一次性錯(cuò)誤”哈。以后的使用不會(huì)再出現(xiàn)了，可能安裝好設(shè)備后，那個(gè)錯(cuò)誤的指令就不再被調(diào)用到了吧。

二、我的本本dell inspiron1720

這個(gè)電腦的存儲(chǔ)控制器上掛載的設(shè)備也比較多。機(jī)器芯片組是965pm+ich8m，除了掛了2塊內(nèi)置硬盤，還有個(gè)turbomemory。

問(wèn)題1：計(jì)算機(jī)管理工具里面修改盤符后不能立即在我的電腦里刷新，必須重新啟動(dòng)計(jì)算機(jī)。

我 電腦里面硬盤和分區(qū)很多，剛安裝時(shí)，系統(tǒng)分配的盤符和我預(yù)先規(guī)劃的不一樣。在計(jì)算機(jī)管理工具里面修改盤符后不能立即在我的電腦里刷新，必須重新啟動(dòng)計(jì)算 機(jī)。這倒是有點(diǎn)像上面530機(jī)器的第二個(gè)問(wèn)題。不過(guò)還好，調(diào)整盤符的事情一般發(fā)生很少，單塊硬盤也不會(huì)產(chǎn)生什么盤符次序不對(duì)。

問(wèn)題2：不能正常休眠。

計(jì)算機(jī)可以正常睡眠，但是不能正常休眠。

睡眠是關(guān)閉一些外圍設(shè)備，將處理器設(shè)置為最節(jié)能模式（甚至關(guān)閉寄存器），但是內(nèi)存還是在工作的，內(nèi)存狀態(tài)得以保存。

休眠就更進(jìn)一步關(guān)閉內(nèi)存了，計(jì)算機(jī)被使用的內(nèi)存將被寫進(jìn)硬盤，下次開(kāi)機(jī)可以恢復(fù)休眠前的狀態(tài)。

intel 的turbomemory可以將一部分休眠的文件放進(jìn)板子上插的turbomemory卡，加快啟動(dòng)速度。但是我在windows7里，從休眠恢復(fù)時(shí)直接 藍(lán)屏。報(bào)錯(cuò)的驅(qū)動(dòng)是iaNvStor.sys（閃的太快沒(méi)太看清，dump也被清理了，但是肯定是turbomemory驅(qū)動(dòng)，驅(qū)動(dòng)版本 1.10.0.1003 2009/4/2）。下次有空抓的全dump看看能不能發(fā)現(xiàn)什么問(wèn)題哈。

這里總結(jié)了一下我遇到的問(wèn)題，都不是 一些大問(wèn)題，很多都是“一次性問(wèn)題”自己折騰折騰也就可以很好解決。這里分享一下可以讓大家少走彎路哈。不過(guò)我覺(jué)得這些問(wèn)題都與我電腦被我diy的厲害有 關(guān)。我老爸的thinkpad單硬盤、沒(méi)裝turbomemory卡，一點(diǎn)問(wèn)題都沒(méi)有。這種硬件結(jié)構(gòu)被改復(fù)雜了，或者是“一次性問(wèn)題”估計(jì)測(cè)試時(shí)也不容易 發(fā)現(xiàn)哈，畢竟測(cè)試環(huán)境不可能面面俱到。隨著正式發(fā)布時(shí)間的臨近，估計(jì)問(wèn)題也會(huì)被逐一解決。

文/旭