節內容：16位匯編學習環境的搭建。
■匯編語言程序設計編程調試過程：分為編輯、匯編、連接和調試四個步驟。
■16位匯編語言學習環境搭建：DosBox虛擬機、Notepad++文本編輯工具、MASM5.0匯編器、Link鏈接器、Lib庫工具和debug調試器。
從這節開始，我們正式開始學習16位匯編語言程序設計。根據計算機發展的歷程，我們按照16位匯編、32位匯編、Win32匯編和64位匯編的順序學習。構建前后銜接，完整的知識體系，這也是系統學習任何一門技術的基本要求。
在學習的過程中，一定要動手實驗，動腦思考，身邊準備好紙和筆，切不可盲目自信或妄自菲薄。任何一門技術的學習和積累都需要一個長期的由量變到質變的過程。當我們認真完成所有的實驗和練習，一定會收獲滿滿，并為我們下一步的學習打下堅實的基礎。好了，讓我們開始吧。
第一步：編寫源程序。
第二步：匯編源程序。
第三步：鏈接目標程序。
第四步：調試可執行程序。
圖5-1 匯編語言程序設計編程調試過程
我們把匯編語言程序設計編寫調試過程分為四個步驟。如圖5-1所示：
■第一步編輯：在第一步編輯源程序之前，一定要先設計程序的結構，定義程序中需要使用的數據結構，并分析實現功能所需要的算法。請記住“程序=數據結構+算法”。
程序設計采用自頂向下的方法。先把程序分為幾個大的功能模塊，通常為：
●數據定義——選擇合適的數據結構；
●功能實現——通過特定算法實現既定任務；
●結果輸出——屏幕輸出、打印輸出或者以文件形式保存到磁盤。
然后我們再將大的模塊細分。我們將在第十章8086匯編語言程序設計基礎的章節中詳細講解三種基本的程序設計結構（順序結構、分支結構和循環結構），此處不再贅述。編寫完源程序之后，將源程序保存為.ASM后綴名的源文件，之后就可以使用匯編器進行編譯了。
■第二步匯編：在16位匯編中，我們采用微軟的MASM5.0匯編器進行編譯。匯編器的作用是將程序員編寫的由字符串構成的匯編語言源文件翻譯成二進制機器語言。機器語言與匯編指令是一一對應的關系，翻譯的過程即查表。編譯完成后，會生成以.OBJ為后綴名的目標代碼程序文件。
為什么編譯后生成.OBJ中間文件，而不是直接生成二進制可執行文件.EXE程序呢？
這是因為當我們需要使用外部功能模塊時（一般以函數調用的方式使用），需要將外部模塊的.OBJ添加到我們的源程序中，這就需要第三步連接。
■第三步連接：使用鏈接器LINK.EXE將一個或多個.OBJ連接生成一個獨立的.EXE二進制可執行程序。接下來就是最后一步調試。
■第四步調試：由于連接后生成的.EXE程序可能會存在問題，我們稱之為BUG。需要借助調試工具Debug.exe單步跟蹤調試，直到修正BUG，確保程序的正確性。
提示
編譯源程序之前的程序設計、數據定義和算法分析非常重要。作為一個合格的程序員，一定要嚴格按照既定的流程和步驟進行軟件開發。這些流程和步驟是前人經驗教訓的總結。很多初學者往往會忽視流程的作用，認為按照流程作業比較麻煩，浪費時間。而事實恰恰相反，計算機語言和人類語言的區別在于，計算機語言需要嚴謹的邏輯，每一處細節都不能出錯。人類的大腦暫且達不到這樣的要求，所以要求程序員先使用紙和筆進行算法演算，寫偽代碼，畫流程圖。如果省略了前面的準備工作，直接編寫代碼，注定是漏洞百出。反復的修改和測試會浪費大量的時間，甚至導致徹底失敗。初學者一旦養成壞的習慣，當意識到問題的嚴重性之后，往往很難改掉。切記悔不當初！
在一堆枯燥的概念之后，終于到了激動人心的時刻了。我們可以編寫自己的第一個程序了。但是在這之前，還需要搭建好必要的環境。16位匯編的環境包請在編程達人的官方網站http://www.bcdaren.com/下載，或者在滴水逆向聯盟論壇下載http://www.dtdebug.com/。
■DOS操作系統環境
因為我們現在普遍使用的是Windows 64位系統，而16位匯編程序需要在DOS系統環境下運行。所以我們需要安裝DosBox虛擬機。安裝的過程非常簡單。點擊運行DosBox0.74-win32-installer.exe。如圖5-2所示，每次都選擇Next下一步即可。接下來還需要安裝源文件的文本編輯工具。
●DosBox安裝完成后啟動，開機界面如圖5-3所示。
●DOS系統命令可以在命令行輸入“help”命令查詢。常用的命令有：CLS清屏、CD顯示或更改當前路徑。其他命令可以參考圖5-4。
●接下來配置虛擬機內的編譯環境路徑。如圖5-5所示，命令行輸入“mount c d:\code\dos\masm”。表示將DosBox虛擬機的C盤根目錄等同于真實機的當前編譯環境路徑。然后在命令行輸入“c:”，將編譯路徑切換到虛擬機C盤根目錄，就可以在此路徑下進行編譯鏈接和調試了。本機將16位匯編工具包放置在“d:\code\dos\masm”路徑下作為當前編譯環境，16位匯編源程序放置在“D:\code\dos\masm\asm”文件夾內。讀者可以將其替換為自己機器內的編譯路徑。
圖5-2 DosBox安裝
圖5-3 DOSBOX開機界面
圖5-4 DOS系統命令
圖5-5 DosBox編譯環境路徑設置
提示
配置好DosBox虛擬機系統環境之后，我們會發現，每次重啟DosBox虛擬機，都需要重新設置編譯環境。為了簡化這個步驟，可以添加一個批處理命令。具體方法如下：
選中DosBox虛擬機桌面快捷方式，點擊鼠標右鍵，點擊“屬性”，打開屬性對話框后，點擊“打開文件所在位置”菜單，在DosBox安裝目錄下找到批處理文件“DosBox 0.74 Options.bat”并打開。在批處理文件的結尾添加如下腳本命令：
mount c d:\code\dos\masm
c:
根據每個人的工具包放置路徑不同，指定自己的工具包路徑。如果不需要使用此批處理命令，可以在腳本命令第一個字母前添加“#”屏蔽，如“#mount c d:\code\dos\masm”。
■文本編輯工具：Notepad++
匯編語言源程序的文本編寫工具軟件，可以使用記事本或任一文本編輯工具。從方便快捷的角度出發，我們推薦使用Nodtepad++文本編輯工具。如果讀者有習慣偏好，可以使用其他自己喜歡的文本編輯工具。
Notepad++。安裝的過程同樣非常簡單，如圖5-6所示，每次都選擇下一步即可。
圖5-6 Notepad++安裝
■MASM.EXE 5.0匯編器
MASM [/options] [source(.asm)],[out(.obj)],[list(.lst)],[cref(.crf)] [;]
可選的命令動作選項由符號“/”引導。利用命令“MASM /HELP”可獲得有關命令動作選項及其說明信息。
source(.asm)指定源程序，缺省擴展名為ASM。
out(.obj)指定輸出的目標代碼文件。缺省的文件名同源文件名，缺省的擴展名為OBJ。
list(.lst)指定輸出的列表文件，缺省擴展名是LST。缺省情況下不生成列表文件。
cref(.crf)指定輸出的交叉參考文件，缺省的擴展名是CRF。缺省情況是不生成交叉參考文件。
命令行最后的[;]表示其后的缺省項，按缺省處理。
舉例說明：匯編程序HELLO.ASM，在當前路徑下編譯HELLO.ASM源程序。
C>MASM HELLO
■LINK.EXE 鏈接器
LINK [/options] [source(.obj)...],[out(.exe)],[mapfile(.map)],[library(.lib)...] [;]
可選的命令動作選項由符號“/”引導。利用命令“LINK /HELP”可獲得有關命令動作選項及其說明信息。
source(.obj)指定目標代碼文件，缺省擴展名為OBJ。可以有多個目標程序代碼文件，文件標識間用加號間隔或者用空格間隔。
out(.exe)指定輸出的可執行文件。缺省的文件名同第一個目標代碼模塊的文件名，缺省的擴展名為EXE。
mapfile(.map)指定輸出定位圖文件，缺省擴展名是MAP。缺省情況下不生成定位圖文件。
library(.lib)指定連接時使用的庫文件，缺省的擴展名是LIB。可以有多個庫，庫文件標識間加號間隔或者使用空格間隔。缺省情況下不使用庫。
命令行最后的[;]表示其后的缺省項，按缺省設置處理。
C>LINK HELLO;
C>LINK TEST1+TEST2,TEST; TEST1和TEST2連接，生成的可執行程序存放在TEST.EXE中。
C>LINK ABC+DEF.LIB 把目標代碼模塊ABC.OBJ與庫DEF.LIB內的函數（過程）連接，生成的可執行程序文件存放在ABC.EXE中。
C>LINK TEST1+TEST2+DEF.LIB ,ABC.EXE,GHI.MAP 把主目標模塊TEST1.OBJ和TEST2.OBJ與庫DEF.LIB內的函數（過程）連接，生成的可執行程序文件存放在ABC.EXE中，生成定位圖文件GHI.MAP。
動手實驗6：匯編器masm.exe和鏈接器link.exe的使用方法
我們以第九章 8086匯編基礎中的第一個匯編程序hello.asm為例。
第一步：編譯源程序hello.asm，生成.obj文件。
如圖5-7所示，命令行輸入：“masm c:\asm\hello”。
“masm”表示執行masm.exe匯編器，“c:\asm\hello”為參數，即hello.asm源文件的路徑，默認缺省“.asm”后綴名。
回車后，“Object filename [hello.OBJ]:”，表示編譯后生成的OBJ文件名。直接回車，表示默認生成“hello.obj”。
下一行 “Source listing [NUL.LIST]:”，表示編譯后生成的list文件名。
再下一行“cross-reference [NUL.CRF]:”，表示編譯后生成的CRF文件名。
List文件和CRF文件，我們在這里不再贅述，將在第三部分32位匯編中講述。
圖5-7 masm匯編器
第二步：將.obj文件鏈接生成.exe二進制可執行文件。
如圖5-8所示，命令行輸入“link hello”。
圖5-8 link鏈接器
“link”表示執行link.exe鏈接器，“hello”為參數，即當前路徑下的hello.obj文件徑，默認缺省“.obj”后綴名。
回車后，“Run File [HELLO.EXE]:”，表示鏈接后生成的EXE文件名。直接回車，表示默認生成“HELLO.EXE”。
下一行 “List File [NUL.MAP]:”，表示鏈接后生成的MAP文件名。
再下一行“Libraries [.LIB]:”，表示鏈接時連接的LIB庫。
MAP文件，我們在這里不再贅述，將在第三部分32位匯編中講述。
LIB庫和多個OBJ文件的鏈接，我們將在第二十七章子程序庫中詳細講述。
注意
注意：除了微軟的MASM匯編器之外，還有TASM、NASM等其他廠商的匯編器，不同廠商的匯編器及相應的鏈接器的語法會有差異，甚至完全不同，如GNU匯編。本書只涉及微軟的匯編語言開發工具包。
本文摘自編程達人系列教材《X86匯編語言基礎教程》。
在給各位朋友免費分析 .NET程序 各種故障的同時，往往也會收到各種其他類型的dump，比如：Windows 崩潰，C++ 崩潰，Mono 崩潰，真的是啥都有，由于基礎知識的相對缺乏，分析起來并不是那么的順利，今天就聊一個 Windows 崩潰的內核dump 吧，這個 dump 是前幾天有位朋友給到我的，讓我幫忙看一下，有了dump之后上 windbg 分析。
只要是 Windows 平臺上的崩潰，操作系統都會維護一個 EXCEPTION_POINTERS 結構體，這個結構體的解讀對分析問題非常重要，使用 !analyze -v 命令簡要輸出如下：
2: kd> !analyze -v
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************
UNEXPECTED_STORE_EXCEPTION (154)
The store component caught an unexpected exception.
Arguments:
Arg1: ffffb402b9851000, Pointer to the store context or data manager
Arg2: ffffe607bc53df30, Exception information
Arg3: 0000000000000002, Reserved
Arg4: 0000000000000000, Reserved
...
EXCEPTION_RECORD: ffffe607bc53eeb8 -- (.exr 0xffffe607bc53eeb8)
ExceptionAddress: fffff80025b04bd0 (nt!RtlDecompressBufferXpressLz+0x0000000000000050)
ExceptionCode: c0000006 (In-page I/O error)
ExceptionFlags: 00000000
NumberParameters: 3
Parameter[0]: 0000000000000000
Parameter[1]: 0000023f30ee99f0
Parameter[2]: 00000000c0000185
Inpage operation failed at 0000023f30ee99f0, due to I/O error 00000000c0000185
EXCEPTION_PARAMETER1: 0000000000000000
EXCEPTION_PARAMETER2: 0000023f30ee99f0
CONTEXT: ffffe607bc53e6f0 -- (.cxr 0xffffe607bc53e6f0)
rax=fffff80025b04b80 rbx=ffff9d808d7fa000 rcx=ffff9d808d7fa000
rdx=ffff9d808d7fa000 rsi=0000000000000002 rdi=0000023f30ee99f0
rip=fffff80025b04bd0 rsp=ffffe607bc53f0f8 rbp=0000023f30eea2fe
r8=0000023f30ee99f0 r9=0000000000000964 r10=ffff9d808d7faea0
r11=0000023f30eea354 r12=ffffe607bc53f368 r13=ffffb402d84d8000
r14=ffff9d808d7fb000 r15=0000000000000000
iopl=0 nv up ei pl zr na po nc
cs=0010 ss=0000 ds=002b es=002b fs=0053 gs=002b efl=00050246
nt!RtlDecompressBufferXpressLz+0x50:
fffff800`25b04bd0 418b08 mov ecx,dword ptr [r8] ds:002b:0000023f`30ee99f0=????????
Resetting default scope
...
從卦中信息看，是由于將地址 0000023f30ee99f0 所映射的物理內存頁換入到內存中，拋了一個IO錯誤，從匯編指令 ecx,dword ptr [r8] ds:002b:0000023f30ee99f0=???????? 上也能看的出來。
如果大家不信，可以用 !vtop 和 !pte 觀察下它們對應的物理地址和物理頁號，都是找不到的。
2: kd> !vtop 0 000000006d34aca0
Amd64VtoP: Virt 000000006d34aca0, pagedir 00000003d81fb002
Amd64VtoP: PML4E 00000003d81fb002
Amd64VtoP: PML4E read error 0x8000FFFF
Virtual address 6d34aca0 translation fails, error 0x8000FFFF.
2: kd> !pte 000000006d34aca0
VA 000000006d34aca0
PXE at FFFF86432190C000 PPE at FFFF864321800008 PDE at FFFF864300001B48 PTE at FFFF860000369A50
contains 0000000000000000
contains 0000000000000000
not valid
有了這個初步信息之后，接下來就來觀察異常時的寄存器上下文和線程棧信息，輸出如下：
2: kd> .cxr 0xffffe607bc53e6f0 ; k
rax=fffff80025b04b80 rbx=ffff9d808d7fa000 rcx=ffff9d808d7fa000
rdx=ffff9d808d7fa000 rsi=0000000000000002 rdi=0000023f30ee99f0
rip=fffff80025b04bd0 rsp=ffffe607bc53f0f8 rbp=0000023f30eea2fe
r8=0000023f30ee99f0 r9=0000000000000964 r10=ffff9d808d7faea0
r11=0000023f30eea354 r12=ffffe607bc53f368 r13=ffffb402d84d8000
r14=ffff9d808d7fb000 r15=0000000000000000
iopl=0 nv up ei pl zr na po nc
cs=0010 ss=0000 ds=002b es=002b fs=0053 gs=002b efl=00050246
nt!RtlDecompressBufferXpressLz+0x50:
fffff800`25b04bd0 418b08 mov ecx,dword ptr [r8] ds:002b:0000023f`30ee99f0=????????
*** Stack trace for last set context - .thread/.cxr resets it
# Child-SP RetAddr Call Site
00 ffffe607`bc53f0f8 fffff800`25a5bc10 nt!RtlDecompressBufferXpressLz+0x50
01 ffffe607`bc53f110 fffff800`25a5bb14 nt!RtlDecompressBufferEx+0x60
02 ffffe607`bc53f160 fffff800`25a5b9a1 nt!ST_STORE<SM_TRAITS>::StDmSinglePageCopy+0x150
03 ffffe607`bc53f220 fffff800`25b56ff0 nt!ST_STORE<SM_TRAITS>::StDmSinglePageTransfer+0xa5
04 ffffe607`bc53f270 fffff800`25b57904 nt!ST_STORE<SM_TRAITS>::StDmpSinglePageRetrieve+0x180
05 ffffe607`bc53f310 fffff800`25b57aed nt!ST_STORE<SM_TRAITS>::StDmPageRetrieve+0xc8
06 ffffe607`bc53f3c0 fffff800`25a5c071 nt!SMKM_STORE<SM_TRAITS>::SmStDirectReadIssue+0x85
07 ffffe607`bc53f440 fffff800`25aad478 nt!SMKM_STORE<SM_TRAITS>::SmStDirectReadCallout+0x21
08 ffffe607`bc53f470 fffff800`25a5cb57 nt!KeExpandKernelStackAndCalloutInternal+0x78
09 ffffe607`bc53f4e0 fffff800`25a5713c nt!SMKM_STORE<SM_TRAITS>::SmStDirectRead+0xc7
0a ffffe607`bc53f5b0 fffff800`25a56b70 nt!SMKM_STORE<SM_TRAITS>::SmStWorkItemQueue+0x1ac
0b ffffe607`bc53f600 fffff800`25b58727 nt!SMKM_STORE_MGR<SM_TRAITS>::SmIoCtxQueueWork+0xc0
0c ffffe607`bc53f690 fffff800`25b2b94b nt!SMKM_STORE_MGR<SM_TRAITS>::SmPageRead+0x167
0d ffffe607`bc53f700 fffff800`25ad1020 nt!SmPageRead+0x33
0e ffffe607`bc53f750 fffff800`25ad023d nt!MiIssueHardFaultIo+0x10c
0f ffffe607`bc53f7a0 fffff800`25a6e818 nt!MiIssueHardFault+0x29d
10 ffffe607`bc53f860 fffff800`25c0b6d8 nt!MmAccessFault+0x468
11 ffffe607`bc53fa00 00007ff8`c3089fa2 nt!KiPageFault+0x358
12 00000067`4ca7f270 00000000`00000000 0x00007ff8`c3089fa2
從卦中的調用棧信息看，代碼的源頭是 用戶態 (0x00007ff8c3089fa2) 過來的，應該是訪問用戶態地址 0000023f30ee99f0 上的內容，由于對應的物理頁不在內存中，觸發了 nt!KiPageFault 中斷，也就是 idt 表中的 0xe號標記的 缺頁中斷, 輸出如下：
lkd> !idt
Dumping IDT: fffff8050ce87000
00: fffff80506206400 nt!KiDivideErrorFault
...
0e: fffff80506209980 nt!KiPageFault
在缺頁中斷中觸發了 IO 操作 MiIssueHardFaultIo 要從pagefiles 中撈頁面，接下來就是頁讀取邏輯 SmPageRead，最后在 RtlDecompressBufferXpressLz 中引發了藍屏。
如果心比較細的話，你會發現有一個關鍵詞 Decompress ，對，就是解壓縮，為什么換入的page還要解壓縮呢？ 這就是我們的突破點。
要找到這個問題的答案，需要觀察下這個異常線程的詳細信息，可以用 .thread 切到異常的線程上下文，再用 !thread 觀察。
2: kd> .thread
Implicit thread is now ffffb402`be04a080
2: kd> !thread ffffb402`be04a080
THREAD ffffb402be04a080 Cid 0594.2228 Teb: 000000674c5b8000 Win32Thread: 0000000000000000 RUNNING on processor 2
Not impersonating
GetUlongFromAddress: unable to read from fffff8002641152c
Owning Process ffffb402b8d58080 Image: <Invalid process>
Attached Process ffffb402b984a040 Image: MemCompression
fffff78000000000: Unable to get shared data
Wait Start TickCount 649763
Context Switch Count 9 IdealProcessor: 0
ReadMemory error: Cannot get nt!KeMaximumIncrement value.
UserTime 00:00:00.000
KernelTime 00:00:00.000
Win32 Start Address 0x00007ff8c808afb0
Stack Init ffffe607bc53fb90 Current ffffe607bc53e800
Base ffffe607bc540000 Limit ffffe607bc539000 Call 0000000000000000
Priority 8 BasePriority 7 PriorityDecrement 0 IoPriority 2 PagePriority 2
Child-SP RetAddr : Args to Child : Call Site
ffffe607`bc53de78 fffff800`25d9856e : 00000000`00000154 ffffb402`b9851000 ffffe607`bc53df30 00000000`00000002 : nt!KeBugCheckEx
ffffe607`bc53de80 fffff800`25c189db : ffffb402`b9851000 ffffe607`bc53df30 ffffe607`00000002 ffffe607`bc53dfe0 : nt!SMKM_STORE<SM_TRAITS>::SmStUnhandledExceptionFilter+0x7e
ffffe607`bc53ded0 fffff800`25bcfb1f : fffff800`00000002 fffff800`258d905c ffffe607`bc539000 ffffe607`bc540000 : nt!`SMKM_STORE<SM_TRAITS>::SmStDirectReadIssue'::`1'::filt$0+0x22
ffffe607`bc53df00 fffff800`25c062ff : fffff800`258d905c ffffe607`bc53e4e0 fffff800`25bcfa80 00000000`00000000 : nt!_C_specific_handler+0x9f
...
從卦中信息看，異常線程還有一個附加的進程 ffffb402b984a040，來自于 MemCompression 模塊，從名字上看所謂的 壓縮解壓縮 邏輯應該和它有關系，接下來到網上去搜一下，有一篇文章說的非常好： https://www.howtogeek.com/319933/what-is-memory-compression-in-windows-10/
大意：這是 Windows10 新增的一個功能，用內存壓縮技術讓RAM中可以存儲更多的內存頁，相比傳統的交換到 PageFiles.sys 有更高的性能，缺點就是需要耗費一些解壓縮需要的 CPU 時間。
在 Windows10 上也能窺探一二：
解決辦法很簡單，學 4S 店的問題解決之道，能換的就堅決不修，讓朋友把 內存壓縮 給關掉，這樣就不走
RtlDecompressBufferXpressLz 邏輯，理論上就不會有什么問題了。
關閉之后，據朋友反饋，這幾天沒有崩潰了。
分析內核態相比用戶態難度要大的多，需要對操作系統以及CPU的相關知識有一個比較深度的理解，任重道遠。。。