給出內存中用戶驅動程序的初始狀態,我們可以記錄提供給CPU的指令,將程序重新加載到初始狀態並播放CPU指令,並使程序像用戶使用它時一樣運行,沒有用戶在那裏?我們可以記錄給CPU的指令嗎?
對不起,如果這個問題寫得不好,或混淆。
給出內存中用戶驅動程序的初始狀態,我們可以記錄提供給CPU的指令,將程序重新加載到初始狀態並播放CPU指令,並使程序像用戶使用它時一樣運行,沒有用戶在那裏?我們可以記錄給CPU的指令嗎?
對不起,如果這個問題寫得不好,或混淆。
最有可能!可以在調試器中逐步執行程序,按指令執行指令。您還必須以某種形式記錄說明,但程序源代碼或可執行文件也可能工作得很好。
某些程序喜歡存儲網絡日誌或操作日誌等內容,以便在某個時間點存儲程序狀態。數據庫也可能存儲重要信息,這些信息在程序「失敗」時也可以查看。像日誌一樣簡單的東西可以用於記錄對程序的輸入。
爲了逐步執行指令,您應該能夠在GDB中使用nexti
和stepi
命令以便按指令執行指令。我們也可以使用disassemble
來獲得應該與各個CPU指令相匹配的彙編指令。在LLDB和MSVC的調試器中也應該有類似的東西。
而現在,對於「內存用戶驅動程序的狀態:」我的例子
它的死亡的Windows藍屏,但我們可以看到,Windows實際上創建了一個物理內存轉儲,並使用內核的調試器。
可以假定物理內存轉儲可以用來發現系統當時的問題以及導致操作系統崩潰的原因。
至於記錄單個指令,程序可執行文件本身應足以記錄究竟發生了什麼,因爲程序的執行路徑明確地由其使用的功能和操作定義。除非您在運行時編寫執行代碼時使用某種運行時元編程,否則應該能夠分析。而且,即使您在運行時編寫執行代碼,也應該能夠從良好的內存轉儲中提取內容,可能是在沙盒環境內或通過元程序來提取失敗程序的狀態。
相關:http://www.unknownroad.com/rtfm/gdbtut/gdbadvanced.html#STEPI
如果用戶沒有在與程序交互,你沒有存儲輸入(或相互作用的其他形式)的歷史,答案顯然是否定的。
一個完整的執行跟蹤可以是巨大的(每秒千兆1個指示...)
這是哪個系統上正在運行的問題。跟蹤調試的目的通常是可能的,一些CPU有特殊的跟蹤指令。您可以記錄程序的每一步,包括所有數據訪問。這個想法是稍後找出哪些程序流程已執行,哪些數據在程序的哪個部分被訪問。
我不知道有任何工具可以讀回這樣的痕跡,並像原始程序那樣工作。
使用模擬用戶輸入運行程序是另一部分,但與您的想法無關。在這裏,程序的輸入將針對某些創建或記錄的數據源運行。在大多數沒有任何問題的系統上工作。特別是在基於X-Windows的GUI系統上,模擬事件並將它們播放到X Windows消息管道中非常容易。
另一種解決方案是使用一種虛擬用戶。您可以編程或記錄用戶交互並每次運行程序。這些解決方案可以在Windows和Linux系統上找到。維基百科給出的工具,一個長長的清單:http://en.wikipedia.org/wiki/List_of_GUI_testing_tools
而且看一看的sikuli http://www.sikuli.org/
回答你的問題是NO。假設您的系統只有一個進程,系統仍然會響應中斷。這種中斷可以隨時發生。如果沒有在相同的相對時間發生完全相同的外部事件,則重新處理中斷將毫無意義。
你的問題背後的目標是什麼?調試?測試?模擬?一切皆有可能,但所有解決方案都不相同如果您提供更多信息,我們可以提供更好的幫助:-) – Klaus