__debugbreak 语句不触发断点

发布于 2024-11-26 17:50:10 字数 375 浏览 0 评论 0原文

在我的 Visual C++ 代码中,我引入了一个 __debugbreak 语句来触发断点。我已经使用 /CLR 选项编译了该项目。但执行过程中不会触发断点。为什么会出现这种情况?在我开枪自杀之前请帮忙。这是 64 位可执行文件。

编辑:我现在尝试使用 DebugBreak() 语句,它现在永远挂起,不确定在哪个语句。该 dll 由服务器程序使用,我从另一台计算机上的客户端访问该程序。这是造成问题的原因吗?我应该从服务器机器本身运行它吗?我希望它至少报告一条有关触发断点的消息,即使它无法在客户端计算机上成功启动调试器会话。 .pdb 文件位于服务器上与 dll 相同的位置。

更新:我刚刚尝试在服务器计算机本身上运行客户端程序,但 DebugBreak() 仍然会导致无限挂起。调试器会话未启动。

In my visual C++ code I have introduced a __debugbreak statement for triggering a breakpoint. I have compiled the project with /CLR option. But it does not trigger a breakpoint during execution. Why does this happen? Please help before I shoot myself. This in on 64 bit executable.

Edit: I tried with DebugBreak() statement now and it is now hanging forever, not sure at which statement. The dll is used by a server program, which I'm accessing from a client on a different machine. Is this what is causing the problem? Should I be running it from the server machine itself? I expected it to atleast report a message about a breakpoint being triggered, even if it could not successfully launch the debugger session on the client machine. The .pdb file is avaialable on the server at the same location as the dll.

Update: I just tried ran the client program on the server machine itself, but still the DebugBreak() causes an infinite hanging. The debugger session does not get launched.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(3

歌枕肩 2024-12-03 17:50:10

为什么不能在调试器中使用 F9(断点)?
不过,DebugBreak(); 应该可以工作。

如果DLL/EXE无法直接加载,您可以从“调试”菜单中“附加到进程”(希望您使用的是Visual Studio)。

Why cannot you use F9 (Breakpoint) from within the debugger?
A DebugBreak(); should work however.

If DLL/EXE cannot be loaded directly, you may "Attach To Process" from "Debug" menu (Hope you are using Visual Studio).

所谓喜欢 2024-12-03 17:50:10

我在 C# 中使用此代码,也许您可​​以将其改编为 C++

#if DEBUG
var endTime = DateTime.Now.AddSeconds(30);
while (!System.Diagnostics.Debugger.IsAttached && DateTime.Now < endTime)
  System.Threading.Thread.Sleep(10);

if (System.Diagnostics.Debugger.IsAttached)
{
  System.Diagnostics.Debugger.Break();
}
#endif

I use this code in C#, maybe you can adapt it for C++

#if DEBUG
var endTime = DateTime.Now.AddSeconds(30);
while (!System.Diagnostics.Debugger.IsAttached && DateTime.Now < endTime)
  System.Threading.Thread.Sleep(10);

if (System.Diagnostics.Debugger.IsAttached)
{
  System.Diagnostics.Debugger.Break();
}
#endif
夜夜流光相皎洁 2024-12-03 17:50:10

虽然 @user1772138 的答案对于 C♯ 来说是正确的,但对于现代 C++,更合适的解决方案是:

#if DEBUG && (__WIN32 || __WIN64)
#include <chrono>
#include <ctime>
#include <thread>
#include <windows.h>
#include <debugapi.h>
using namespace std::chrono_literals;
using std::chrono::system_clock;
#endif // DEBUG

然后,在你的 main 中:

int main(int argc, char *argv[]) {
#if DEBUG && (__WIN32 || __WIN64)
    auto endTime = system_clock::now() + 30s;
    while (!::IsDebuggerPresent() && system_clock::now() < endTime) {
        std::this_thread::sleep_for(10s);
    }

    if (::IsDebuggerPresent()) {
        __debugbreak();
    }
#endif // DEBUG
// Main code goes here

即使 __debugbreak 不起作用 - 它相当于 C♯ System.Diagnostics.Debugger.Break—第一部分在程序启动前等待 30 秒,如果您在这段时间内已成功附加调试器,则不会需要调用__debugbreak。您只需在生成程序的程序中放置一个中断,然后当您到达该点时,超越它,并在 Visual Studio 调试 -> 附加到进程中附加到该进程...

编辑:添加了一项检查以确保这一点在 Windows 上运行;在 Linux 下,代码会有所不同,但操作人员要求使用 Windows 解决方案。

While @user1772138's answer is correct for C♯, for modern C++, a more appropriate solution is:

#if DEBUG && (__WIN32 || __WIN64)
#include <chrono>
#include <ctime>
#include <thread>
#include <windows.h>
#include <debugapi.h>
using namespace std::chrono_literals;
using std::chrono::system_clock;
#endif // DEBUG

Then, in your main:

int main(int argc, char *argv[]) {
#if DEBUG && (__WIN32 || __WIN64)
    auto endTime = system_clock::now() + 30s;
    while (!::IsDebuggerPresent() && system_clock::now() < endTime) {
        std::this_thread::sleep_for(10s);
    }

    if (::IsDebuggerPresent()) {
        __debugbreak();
    }
#endif // DEBUG
// Main code goes here

Even if __debugbreak doesn't work—it's the equivalent of the C♯ System.Diagnostics.Debugger.Break—the first part waits 30 seconds before the program starts and if you have successfully attached the debugger in this time, you won't need to call the __debugbreak. You just put a break in the program which spawns your program, and then when you reach that point, step beyond it, and attach to the process in Visual Studio Debug->Attach to Process…

EDIT: Added a check to make sure this is running on Windows; under Linux the code would be different, but the op was asking for a Windows solution.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文