TL;DR：除錯到MFC ( CString) 頭代碼在我的兩臺機器上都不起作用，據我所知，這是由于這些頭檔案的編譯方式特殊。
通過反匯編輸入時單步執行 MFC 標頭代碼有效，但設定 Brealpoints 不起作用。
我正在尋找一種解決方法或至少承認我的分析。
系統：
- Visual Studio 2019 專業版 16.9.6
- Windows 10 / 1809 企業版 LTSC
設定：（我為這很長而道歉。）
創建 Visual Studio 2019 示例 MFC 應用程式專案（SDI 應用程式）
確保選中
Enable Just My Code是關在選項- >除錯- >常規。將構建配置設定為 Debug/x64（沒有區別，但讓我們都保持在同一頁面上）
導航至
MFCApplication1.cpp->CMFCApplication1App::InitInstance()像這樣插入一個 CString init：
... InitCommonControlsEx(&InitCtrls); CWinAppEx::InitInstance(); // please put breakpoint 1 here // Add this line and set breakpoints CString this_is_text(L"Debugging into CString Header does not work!"); // breakpoint 2 here
現在，您可以在除錯器下啟動程式，您應該在第一個斷點處停止：
現在，確保所有符號都已加載，最簡單的方法是通過呼叫堆疊完成：
只需選擇呼叫堆疊視窗中的所有行，然后在背景關系選單中點擊加載符號。之后，呼叫堆疊應大致如下所示：
> MFCApplication1.exe!CMFCApplication1App::InitInstance() Line 75 C
mfc140ud.dll!AfxWinMain(HINSTANCE__ * hInstance=0x00007ff7b5070000, ...) Line 37 C
MFCApplication1.exe!wWinMain(HINSTANCE__ * hInstance=0x00007ff7b5070000, ...) Line 26 C
MFCApplication1.exe!invoke_main() Line 123 C
MFCApplication1.exe!__scrt_common_main_seh() Line 288 C
MFCApplication1.exe!__scrt_common_main() Line 331 C
MFCApplication1.exe!wWinMainCRTStartup(void * __formal=0x000000c2b7084000) Line 17 C
kernel32.dll!BaseThreadInitThunk() Unknown
ntdll.dll!RtlUserThreadStart() Unknown
現在，您可以嘗試單步進入（可能是 F11）該CWinAppEx::InitInstance()功能，該功能應該可以正常作業，讓您登陸mfc140ud.dll!CWinApp::InitInstance() Line 394- 這沒問題。
再次退出，然后嘗試進入CStringctor：
這在我的機器上不起作用！
What I can do however, is (from the point above) switch to disassembly view, step into the calls there and get into the header code this way:
I can then successfully step through (but never into) the MFC header code. Trying to set a breakpoint will result in the error:
The breakpoint will not currently be hit. No executable code of the debugger's code type is associated with this line. Possible causes include ...
C:\Program Files (x86)\Microsoft Visual Studio\2019\Professional\VC\Tools\MSVC\14.28.29910\atlmfc\include\cstringt.h
And this is where I'm at.
Analysis:
What we can see from the MFC code is that we can step into "regular" cpp code, but as soon as we try to step into (or set breakpoint) code that is inside this CStringt.h it breaks.
Peculiar here: This is template header code, and still the executed code (as shown by the disassembly) is not in the user module but in the mfc###.dll! I think they do some clever tricks with the preprocessor (see defined(_MFC_DLL_BLD) and somesuch) which enables this multi use of the header file, and maybe, possibly this is also what breaks the debugger.
Question:
- Is this a known problem, does this happen with all VS2019 installs, is there something peculiar to my setup?
- Maybe fixed in a newer VS version?
- Iff this is actually broken, what would be a useable workaround, other than constantly switching to disassembly view when into the MFC headers.
這里最有趣的答案實際上是關于為什么會中斷 - 除錯器在哪里混淆？這是define除錯庫代碼時重新撰寫代碼的普遍問題嗎？
uj5u.com熱心網友回復：
分析在某些時候橫盤整理，但我們終于在這里找到了問題的一部分：
該Require source files to exactly match the original version選項：
是問題所在，但以一種非常奇特的方式：
當您不需要匹配源檔案（即禁用此默認選項）時，就會發生 OP 的錯誤行為：除錯器無法再將符號與cstringt.h檔案匹配。
不幸的是，我在兩臺機器上都禁用了它。拉入第三臺機器顯示我們可以設定斷點（盡管 F11 仍然不起作用）并且通過比較 VS 設定的 xml 匯出我們發現這是不同的。
所以，長話短說：對我們來說，為了能夠在（未修改！）MFC 標頭中設定斷點，需要我們啟用該Require source files to exactly match ..選項。
如果該選項被禁用，這意味著除錯器的行為更寬松，它將不再起作用。
而且，是的，我們仔細檢查了它始終是相同的源檔案 C:\Program Files (x86)\Microsoft Visual Studio\2019\Professional\VC\Tools\MSVC\14.28.29910\atlmfc\include\cstringt.h
步入/F11 的謎團仍然存在，但我想這最好被帶到一個單獨的問題。
uj5u.com熱心網友回復：
MSVC 附帶的源不匹配。
我認為會發生這種情況，因為 DLL 已使用 Windows 更新或新的 vcredist 進行更新，但 Visual Studio 包含的內容未更新。如果您使用/MT或構建/MTd并靜態鏈接 MFC，則問題不會持續存在。
如果您關心，這可能可以報告給
我知道這適用于 c std:: 庫代碼除錯。當我忘記取消選中此選項時，我使用的另一種技術與您上面描述的類似。
- 在我想要進入的代碼行上設定一個斷點。
- 到達斷點后，在編輯器視窗中右鍵單擊并選擇“Go To Disassemly”。
- 在反匯編模式下，跳過直到你得到一個
call陳述句。這通常是 std 庫。最終，您將導航到程式集和系統代碼源的混合中。您可以通過再次右鍵單擊并選擇“轉到源代碼”來退出反匯編模式。
轉載請註明出處，本文鏈接：https://www.uj5u.com/ruanti/378586.html