1、virtual memory

virtual memory發(fā)音

英：　　美：

virtual memory中文意思翻譯

常見釋義：

虛擬內(nèi)存

virtual memory雙語使用場景

1、Let's look at virtual memory.───我們來看看虛擬內(nèi)存。

2、The actual schema of the table (Listing 1) used in the Informix port of this agent includes how much virtual memory is allocated and used.───該代理的Informix端口中使用的表的實際模式（清單1）包括分配和使用多少虛擬內(nèi)存。

3、It is how much page file space would be used if all the private committed virtual memory in the system had to be paged out all at once.───換言之，如果系統(tǒng)中所有的私有提交虛擬內(nèi)存不得不一次性全部被換出去的話，將用到多少頁面文件空間。

4、Before executing, the test adjusts its total memory usage according to how much real and virtual memory exist on the system.───在執(zhí)行之前，測試會根據(jù)系統(tǒng)中存在多少物理和虛擬內(nèi)存來調(diào)整其總的內(nèi)存使用情況。

5、Reserved memory is the virtual memory space reserved for the application but no disk or main memory pages have been used.───保留內(nèi)存是為應(yīng)用程序保留（但尚未使用任何磁盤或主內(nèi)存頁）的虛擬內(nèi)存空間。

6、Virtual Memory management.───虛擬內(nèi)存管理。

7、Virtual memory interaction.───虛擬內(nèi)存交互。

8、AIX newbies are sometimes surprised to hear that the VMM services all memory requests from the system, not just virtual memory.───有時候，令A(yù)IX新手感到困惑的是，VMM服務(wù)如何處理系統(tǒng)中所有的內(nèi)存請求，而不僅僅是虛擬內(nèi)存本身。

9、If the disk is the same as the one used for virtual memory, then it might be a problem with lack of memory and too much swapping.───如果該磁盤同時用作虛擬內(nèi)存，那么可能是因為缺少內(nèi)存和過多的交換的問題。

virtual memory相似詞語短語

1、virtual currency───虛擬貨幣

2、virtual tourism───虛擬旅游

3、virtual images───[光][天]虛像；[醫(yī)]虛象

4、bazar virtual───虛擬基地

5、virtual environment───[計]虛擬環(huán)境

6、virtual piano───虛擬鋼琴

7、virtual───adj.[計]虛擬的；實質(zhì)上的，事實上的（但未在名義上或正式獲承認(rèn)）

8、virtual slime───虛擬黏液

9、virtual machine───[計]虛擬機(jī)，[計]虛擬計算機(jī)；虛擬計算機(jī); 虛擬機(jī)

2、Windows內(nèi)核調(diào)試器的WinDBG

WinDBG和用戶調(diào)試器一點很大不同是內(nèi)核調(diào)試器在一臺機(jī)器上啟動，通過串口調(diào)試另一個相聯(lián)系的以Debug方式啟動的系統(tǒng)，這個系統(tǒng)可以是虛擬機(jī)上的系統(tǒng)，也可以是另一臺機(jī)器上的系統(tǒng)（這只是微軟推薦和實現(xiàn)的方法，其實象SoftICE這類內(nèi)核調(diào)試器可以實現(xiàn)單機(jī)調(diào)試）。很多人認(rèn)為主要功能都是在WinDBG里實現(xiàn)，事實上并不是那么一回事，windows已經(jīng)把內(nèi)核調(diào)試的機(jī)制集成進(jìn)了內(nèi)核，WinDBG、kd之類的內(nèi)核調(diào)試器要做的僅僅是通過串行發(fā)送特定格式數(shù)據(jù)包來進(jìn)行聯(lián)系，比如中斷系統(tǒng)、中斷點、顯示內(nèi)存數(shù)據(jù)等等。然后把收到的數(shù)據(jù)包經(jīng)過WinDBG處理顯示出來。

在進(jìn)一步介紹WinDBG之前，先介紹兩個函數(shù)：KdpTrace、KdpStub，我在《windows異常處理流程》一文里簡單提過這兩個函數(shù)。現(xiàn)在再提一下，當(dāng)異常發(fā)生于內(nèi)核態(tài)下，會調(diào)用KiDebugRoutine兩次，異常發(fā)生于用戶態(tài)下，會調(diào)用KiDebugRoutine一次，而且第一次調(diào)用都是剛開始處理異常的時候。

當(dāng)WinDBG未被加載時KiDebugRoutine為KdpStub，處理也很簡單，主要是對由int 0x2d引起的異常如DbgPrint、DbgPrompt、加載卸載SYMBOLS（關(guān)于int 0x2d引起的異常將在后面詳細(xì)介紹）等，把Context.Eip加1，跳過int 0x2d后面跟著的int 0x3指令。

真正實現(xiàn)了WinDBG功能的函數(shù)是KdpTrap，它負(fù)責(zé)處理所有STATUS_BREAKPOINT和STATUS_SINGLE_STEP（單步）異常。STATUS_BREAKPOINT的異常包括int 0x3、DbgPrint、DbgPrompt、加載卸載SYMBOLS。DbgPrint的處理最簡單，KdpTrap直接向調(diào)試器發(fā)含有字符串的包。DbgPrompt因為是要輸出并接收字符串，所以先將含有字符串的包發(fā)送出去，再陷入循環(huán)等待接收來自調(diào)試器的含有回復(fù)字符串的包。SYMBOLS的加載和卸載通過調(diào)用KdpReportSymbolsStateChange，int 0x3斷點異常和int 0x1單步異常（這兩個異?；旧鲜莾?nèi)核調(diào)試器處理得最多的異常）通過調(diào)用KdpReportExceptionStateChange，這兩個函數(shù)很相似，都是通過調(diào)用KdpSendWaitContinue函數(shù)。KdpSendWaitContinue可以說是內(nèi)核調(diào)試器功能的大管家，負(fù)責(zé)各個功能的分派。這個函數(shù)向內(nèi)核調(diào)試器發(fā)送要發(fā)送的信息，比如當(dāng)前所有寄存器狀態(tài)，每次單步后我們都可以發(fā)現(xiàn)寄存器的信息被更新，就是內(nèi)核調(diào)試器接受它發(fā)出的包含最新機(jī)器狀態(tài)的包；還有SYMBOLS的狀態(tài)，這樣加載和卸載了SYMBOLS我們都能在內(nèi)核調(diào)試器里看到相應(yīng)的反應(yīng)。然后KdpSendWaitContinue等待從內(nèi)核調(diào)試器發(fā)來的包含命令的包，決定下一步該干什么。讓我們來看看KdpSendWaitContinue都能干些什么：

case DbgKdReadVirtualMemoryApi:

KdpReadVirtualMemory(&ManipulateState,&MessageData,ContextRecord);

break;

case DbgKdReadVirtualMemory64Api:

KdpReadVirtualMemory64(&ManipulateState,&MessageData,ContextRecord);

break;

case DbgKdWriteVirtualMemoryApi:

KdpWriteVirtualMemory(&ManipulateState,&MessageData,ContextRecord);

break;

case DbgKdWriteVirtualMemory64Api:

KdpWriteVirtualMemory64(&ManipulateState,&MessageData,ContextRecord);

break;

case DbgKdReadPhysicalMemoryApi:

KdpReadPhysicalMemory(&ManipulateState,&MessageData,ContextRecord);

break;

case DbgKdWritePhysicalMemoryApi:

KdpWritePhysicalMemory(&ManipulateState,&MessageData,ContextRecord);

break;

case DbgKdGetContextApi:

KdpGetContext(&ManipulateState,&MessageData,ContextRecord);

break;

case DbgKdSetContextApi:

KdpSetContext(&ManipulateState,&MessageData,ContextRecord);

break;

case DbgKdWriteBreakPointApi:

KdpWriteBreakpoint(&ManipulateState,&MessageData,ContextRecord);

break;

case DbgKdRestoreBreakPointApi:

KdpRestoreBreakpoin(&ManipulateState,&MessageData,ContextRecord);

break;

case DbgKdReadControlSpaceApi:

KdpReadControlSpace(&ManipulateState,&MessageData,ContextRecord);

break;

case DbgKdWriteControlSpaceApi:

KdpWriteControlSpace(&ManipulateState,&MessageData,ContextRecord);

break;

case DbgKdReadIoSpaceApi:

KdpReadIoSpace(&ManipulateState,&MessageData,ContextRecord);

break;

case DbgKdWriteIoSpaceApi:

KdpWriteIoSpace(&ManipulateState,&MessageData,ContextRecord);

break;

case DbgKdContinueApi:

if (NT_SUCCESS(ManipulateState.u.Continue.ContinueStatus) != FALSE) {

return ContinueSuccess;

} else {

return ContinueError;

}

break;

case DbgKdContinueApi2:

if (NT_SUCCESS(ManipulateState.u.Continue2.ContinueStatus) != FALSE) {

KdpGetStateChange(&ManipulateState,ContextRecord);

return ContinueSuccess;

} else {

return ContinueError;

}

break;

case DbgKdRebootApi:

KdpReboot();

break;

case DbgKdReadMachineSpecificRegister:

KdpReadMachineSpecificRegister(&ManipulateState,&MessageData,ContextRecord);

break;

case DbgKdWriteMachineSpecificRegister:

KdpWriteMachineSpecificRegister(&ManipulateState,&MessageData,ContextRecord);

break;

case DbgKdSetSpecialCallApi:

KdSetSpecialCall(&ManipulateState,ContextRecord);

break;

case DbgKdClearSpecialCallsApi:

KdClearSpecialCalls();

break;

case DbgKdSetInternalBreakPointApi:

KdSetInternalBreakpoint(&ManipulateState);

break;

case DbgKdGetInternalBreakPointApi:

KdGetInternalBreakpoint(&ManipulateState);

break;

case DbgKdGetVersionApi:

KdpGetVersion(&ManipulateState);

break;

case DbgKdCauseBugCheckApi:

KdpCauseBugCheck(&ManipulateState);

break;

case DbgKdPageInApi:

KdpNotSupported(&ManipulateState);

break;

case DbgKdWriteBreakPointExApi:

Status = KdpWriteBreakPointEx(&ManipulateState,

&MessageData,

ContextRecord);

if (Status) {

ManipulateState.ApiNumber = DbgKdContinueApi;

ManipulateState.u.Continue.ContinueStatus = Status;

return ContinueError;

}

break;

case DbgKdRestoreBreakPointExApi:

KdpRestoreBreakPointEx(&ManipulateState,&MessageData,ContextRecord);

break;

case DbgKdSwitchProcessor:

KdPortRestore ();

ContinueStatus = KeSwitchFrozenProcessor(ManipulateState.Processor);

KdPortSave ();

return ContinueStatus;

case DbgKdSearchMemoryApi:

KdpSearchMemory(&ManipulateState,&MessageData,ContextRecord);

break;

讀寫內(nèi)存、搜索內(nèi)存、設(shè)置/恢復(fù)斷點、繼續(xù)執(zhí)行、重啟等等，WinDBG里的功能是不是都能實現(xiàn)了?呵呵。

每次內(nèi)核調(diào)試器接管系統(tǒng)是通過調(diào)用在KiDispatchException里調(diào)用KiDebugRoutine(KdpTrace），但我們知道要讓系統(tǒng)執(zhí)行到KiDispatchException必須是系統(tǒng)發(fā)生了異常。而內(nèi)核調(diào)試器與被調(diào)試系統(tǒng)之間只是通過串口聯(lián)系，串口只會發(fā)生中斷，并不會讓系統(tǒng)引發(fā)異常。那么是怎么讓系統(tǒng)產(chǎn)生一個異常呢?答案就在KeUpdateSystemTime里，每當(dāng)發(fā)生時鐘中斷后在HalpClockInterrupt做了一些底層處理后就會跳轉(zhuǎn)到這個函數(shù)來更新系統(tǒng)時間（因為是跳轉(zhuǎn)而不是調(diào)用，所以在WinDBG斷下來后回溯堆棧是不會發(fā)現(xiàn)HalpClockInterrupt的地址的），是系統(tǒng)中調(diào)用最頻繁的幾個函數(shù)之一。在KeUpdateSystemTime里會判斷KdDebuggerEnable是否為TRUE，若為TRUE則調(diào)用KdPollBreakIn判斷是否有來自內(nèi)核調(diào)試器的包含中斷信息的包，若有則調(diào)用DbgBreakPointWithStatus，執(zhí)行一個int 0x3指令，在異常處理流程進(jìn)入了KdpTrace后將根據(jù)處理不同向內(nèi)核調(diào)試器發(fā)包并無限循環(huán)等待內(nèi)核調(diào)試的回應(yīng)?，F(xiàn)在能理解為什么在WinDBG里中斷系統(tǒng)后堆?；厮菘梢砸来伟l(fā)現(xiàn)KeUpdateSystemTime->RtlpBreakWithStatusInstruction，系統(tǒng)停在了int 0x3指令上（其實int 0x3已經(jīng)執(zhí)行過了，只不過Eip被減了1而已），實際已經(jīng)進(jìn)入KiDispatchException->KdpTrap，將控制權(quán)交給了內(nèi)核調(diào)試器。

系統(tǒng)與調(diào)試器交互的方法除了int 0x3外，還有DbgPrint、DbgPrompt、加載和卸載symbols，它們共同通過調(diào)用DebugService獲得服務(wù)。

NTSTATUS DebugService(

ULONG ServiceClass,

PVOID Arg1,

PVOID Arg2

）

{

NTSTATUS Status;

__asm {

mov eax,ServiceClass

mov ecx,Arg1

mov edx,Arg2

int 0x2d

int 0x3

mov Status,eax

}

return Status;

}

ServiceClass可以是BEAKPOINT_PRINT(0x1）、BREAKPOINT_PROMPT(0x2）、BREAKPOINT_LOAD_SYMBOLS(0x3）、BREAKPOINT_UNLOAD_SYMBOLS(0x4）。為什么后面要跟個int 0x3，M$的說法是為了和int 0x3共享代碼（我沒弄明白啥意思-_-），因為int 0x2d的陷阱處理程序是做些處理后跳到int 0x3的陷阱處理程序中繼續(xù)處理。但事實上對這個int 0x3指令并沒有任何處理，僅僅是把Eip加1跳過它。所以這個int 0x3可以換成任何字節(jié)。

int 0x2d和int 0x3生成的異常記錄結(jié)（EXCEPTION_RECORD)ExceptionRecord.ExceptionCode都是STATUS_BREAKPOINT(0x80000003），不同是int 0x2d產(chǎn)生的異常的ExceptionRecord.NumberParameters>0且ExceptionRecord.ExceptionInformation對應(yīng)相應(yīng)的ServiceClass比如BREAKPOINT_PRINT等。事實上，在內(nèi)核調(diào)試器被掛接后，處理DbgPrint等發(fā)送字符給內(nèi)核調(diào)試器不再是通過int 0x2d陷阱服務(wù)，而是直接發(fā)包。用M$的話說，這樣更安全，因為不用調(diào)用KdEnterDebugger和KdExitDebugger。

最后說一下被調(diào)試系統(tǒng)和內(nèi)核調(diào)試器之間的通信。被調(diào)試系統(tǒng)和內(nèi)核調(diào)試器之間通過串口發(fā)數(shù)據(jù)包進(jìn)行通信，Com1的IO端口地址為0x3f8，Com2的IO端口地址為0x2f8。在被調(diào)試系統(tǒng)準(zhǔn)備要向內(nèi)核調(diào)試器發(fā)包之前先會調(diào)用KdEnterDebugger暫停其它處理器的運行并獲取Com端口自旋鎖（當(dāng)然，這都是對多處理器而言的），并設(shè)置端口標(biāo)志為保存狀態(tài)。發(fā)包結(jié)束后調(diào)用KdExitDebugger恢復(fù)。每個包就象網(wǎng)絡(luò)上的數(shù)據(jù)包一樣，包含包頭和具體內(nèi)容。包頭的格式如下：

typedef struct _KD_PACKET {

ULONG PacketLeader;

USHORT PacketType;

USHORT ByteCount;

ULONG PacketId;

ULONG Checksum;

} KD_PACKET,*PKD_PACKET;

PacketLeader是四個相同字節(jié)的標(biāo)識符標(biāo)識發(fā)來的包，一般的包是0x30303030，控制包是0x69696969，中斷被調(diào)試系統(tǒng)的包是0x62626262。每次讀一個字節(jié)，連續(xù)讀4次來識別出包。中斷系統(tǒng)的包很特殊，包里數(shù)據(jù)只有0x62626262。包標(biāo)識符后是包的大小、類型、包ID、檢測碼等，包頭后面就是跟具體的數(shù)據(jù)。這點和網(wǎng)絡(luò)上傳輸?shù)陌芟嗨?。還有一些相似的地方比如每發(fā)一個包給調(diào)試器都會收到一個ACK答復(fù)包，以確定調(diào)試器是否收到。若收到的是一個RESEND包或者很長時間沒收到回應(yīng)，則會再發(fā)一次。對于向調(diào)試器發(fā)送輸出字符串、報告SYMBOL情況等的包都是一接收到ACK包就立刻返回，系統(tǒng)恢復(fù)執(zhí)行，系統(tǒng)的表現(xiàn)就是會卡那么短短一下。只有報告狀態(tài)的包才會等待內(nèi)核調(diào)試器的每個控制包并完成對應(yīng)功能，直到發(fā)來的包包含繼續(xù)執(zhí)行的命令為止。無論發(fā)包還是收包，都會在包的末尾加一個0xaa，表示結(jié)束。

現(xiàn)在我們用幾個例子來看看調(diào)試流程。

記得我以前問過jiurl為什么WinDBG的單步那么慢（相對softICE），他居然說沒覺得慢?*$&$^$^(&(&；（我ft。現(xiàn)在可以理解為什么WinDBG的單步和從操作系統(tǒng)正常執(zhí)行中斷下來為什么那么慢了。單步慢是因為每單步一次除了必要的處理外，還得從串行收發(fā)包，怎么能不慢。中斷系統(tǒng)慢是因為只有等到時鐘中斷發(fā)生執(zhí)行到KeUpdateSystemTime后被調(diào)試系統(tǒng)才會接受來自WinDBG的中斷包。現(xiàn)在我們研究一下為什么在KiDispatchException里不能下斷點卻可以用單步跟蹤KiDispatchException的原因。如果在KiDispatchException中某處下了斷點，執(zhí)行到斷點時系統(tǒng)發(fā)生異常又重新回到KiDispatchException處，再執(zhí)行到int 0x3，如此往復(fù)造成了死循環(huán)，無法不能恢復(fù)原來被斷點int 0x3所修改的代碼。但對于int 0x1，因為它的引起是因為EFLAG寄存中TF位被置位，并且每次都自動被復(fù)位，所以系統(tǒng)可以被繼續(xù)執(zhí)行而不會死循環(huán)。現(xiàn)在我們知道了內(nèi)部機(jī)制，我們就可以調(diào)用KdXXX函數(shù)實現(xiàn)一個類似WinDBG之類的內(nèi)核調(diào)試器，甚至可以替換KiDebugRoutine(KdpTrap）為自己的函數(shù)來自己實現(xiàn)一個功能更強大的調(diào)試器，呵呵。