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

2009/9/26 16:25:53    編輯:Windows7之家 - Mary Jane     字體:【

Win7之家afsion.com.cn):Windows 7 RTM存儲控制器 - 一些小問題總結(jié)

用了一段時間的RTM版Windows7,發(fā)現(xiàn)貌似Windows7在存儲控制器方面有些問題,這里做下總結(jié)。

一、我的臺式計算機dell inspiron530

01

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

問題1:安裝時不能正常加載silicon image存儲控制器的驅(qū)動。

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

問題2:自動安裝存儲控制器之后,硬盤和光驅(qū)被計算機管理工具識別,但是我的電腦里不能被加載使用,重啟一下計算機,所有的硬盤和光驅(qū)才可以正常使用。

問題3:安裝存儲控制器驅(qū)動后的第一次關(guān)機不正常。

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

在7260版本時,我過了個十多分鐘就直接強制重啟了,之后的系統(tǒng)一切正常,什么問題都沒有了。

這次是裝RTM版,由于已經(jīng)有了前一次這樣的情況。我直接搬來本本,看著它,看它到底能發(fā)生什么。一直等待了大約半個小時,藍屏了哈。這就意味著我可以去看看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

上面的報錯信息是說一個驅(qū)動導(dǎo)致錯誤的電源狀態(tài),電源傳輸?shù)却床寮从迷O(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

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

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.

這 里給出的就是錯誤的cdrom模塊的信息,這個是微軟提供的驅(qū)動哦。FileDescription:  SCSI CD-ROM Driver,這個是一個scsi類型的驅(qū)動,和我最前面給出的硬件示意圖不同哈。其實這個PCI擴展的存儲控制器是把IDE設(shè)備模擬成scsi設(shè)備的。 這個也就解釋了為什么這個設(shè)備會被定義為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ù)大概功能。先說下Wdf01000.sys這個系統(tǒng)文件,lmvm它一 下,F(xiàn)ileDescription:  Kernel Mode Driver Framework Runtime,這個是個內(nèi)核模式下的驅(qū)動構(gòu)架運行時庫。(哎~~要是有這些內(nèi)核函數(shù)的文檔就好了,真想看哈。

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

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

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

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

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

二、我的本本dell inspiron1720

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

問題1:計算機管理工具里面修改盤符后不能立即在我的電腦里刷新,必須重新啟動計算機。

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

問題2:不能正常休眠。

計算機可以正常睡眠,但是不能正常休眠。

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

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

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

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

文/旭