当另一个DLL中的一个DLL给用户断点命中时，Win 10上的VC6调试 [英] VC6 on Win 10 Debugging when a DLL in another DLL gives User Breakpoint hit
问题描述
我刚刚安装了一台Windows 10计算机，因为现在Windows 7以及旧的经典VC6一起被丢弃了。加上Service Pack 6，并安装了Platform SDK。数十年来，我一直在Windows 7机器上以这种方式使用它，没有任何问题（太久了，为什么不升级到VS 2010、2012、2015、2017、2019，yada yada，yada……太久了…… ）
我提出了一个在年底之前从事的现有项目。大exe，其中包含多个DLL，C ++对象等...在1月1日之前一切正常。
在新安装的Windows 10上，当我尝试在调试器中启动它时，出现了错误：
甚至在调用主之前也会出现。并且可执行文件立即存在，甚至在出现消息框之前，因此没有要检查的堆栈跟踪。自然地，我寻找任何可能会破坏事物的C ++构造函数。但是没有。 （而且我的Windows 7计算机上从来没有任何问题）
我将其范围缩小到以下条件：
主EXE静态链接到LIB / DLL。那个DLL是静态链接到另一个LIB / DLL
的，当我删除了下面的DLL依赖关系时，我就可以在调试器中运行该可执行文件了。几个正在经历此的项目。
我有一个测试项目（dsw和dps文件），如果有人想看的话，至少可以在Windows 10计算机上进行演示。它被剥夺了外壳。链接到DLL的EXE，DLL链接到另一个DLL。如果在链接阶段删除了内部DLL依赖项，则具有单个DLL的可执行文件就可以正常工作。
此外，EXE也将在调试器外部运行。
最后，当我为发布设置配置时，它也可以在IDE中运行，但是没有调试信息。但是，如果我在发行版中启用调试信息，则启动前它会再次崩溃。
因此，显然Windows 10中有某些东西阻止调试容器运行。我也禁用了容错堆堆，但没有更改。
有人遇到过类似的事情吗？
有人有什么建议吗？
-斯科蒂
几年以来，我一直没有使用V6调试器，在进行了另一次搜索以寻求解决方案的地方之后，我终于找到了一种方法并希望与他人共享。对于出现用户断点错误并在启动时立即退出的项目，请使用Build-> Execute（ctrl + F5）启动它们，然后执行Build-> Start Debug-> Attach Process。您将无法对启动做任何事情，但是您可以在计时器或命令中设置断点以进入。我想您可以在调试时将长时间睡眠作为主要呼叫中的第一个调用，以使您有机会获得启动并在那里设置断点。
I just installed a Windows 10 machine, since Windows 7 is now dropped... along with the old, classic VC6. Plus the Service pack 6, and the Platform SDK installed. I have been using it this way with no issues on my Windows 7 machine for decades (too long to go into why not upgrade to VS 2010, 2012, 2015, 2017, 2019, yada yada, yada... Subject for a different debate)
I brought up an existing project I was working in before the end of the year. Big exe, several DLLs in it, C++ objects, etc... Was all working fine before Jan 1st.
On my new Windows 10 install, when I tried to launch it in the debugger, it gave an error:
This appears even before main is called. And the executable immediately exists, even before the message box appears, so there is no stack trace to examine. Naturally I looked for any C++ constructors that might be called which could be corrupting things. But there were none. (and never had any issues on my Windows 7 machine anyway)
I narrowed it to the following condition: The main EXE is linked statically to a LIB/DLL. THAT dll is linked statically to another LIB/DLL When I remove the underneath DLL dependency, I can run the executable in the debugger.
I've found several projects that are experiencing this.
I have a test project (dsw and dps files) which demonstrates this (at least on my Windows 10 machine) if anyone wants to look at it. It is stripped down to nothing but shells. An EXE that is linked to a DLL, which is linked to another DLL. If I remove the inner DLL dependency in the link stage, the executable with a single DLL work fine.
Also, the EXE will run outside the debugger as well. Both debug and release.
Lastly, when I set the configuration for release, it also runs in the IDE, but has no debug info. However if I enable debug info in the release builds, it again crashes before startup.
So apparently there is yet something in windows 10 that is preventing the debugging container from running. I have also disabled the "Fault Tolerant Heap Shim" but no change.
Has anyone experienced something like this?
Does anyone have any advice?
-Scotty
I've been living without our V6 debugger for a few years now, and after doing yet another search hoping for a solution where I wound up here, I finally found a way and wanted to share it. For projects that give a user breakpoint error and exit immediately on startup, launch them with Build->Execute (ctrl+F5), then do a Build->Start Debug->Attach Process. You won't be able to do anything about the startup, but you can set breakpoints at timers or commands to get in. I guess you could put a long sleep as the first call in your main while debugging to give you a chance to get in and get your breakpoints in place there too.
这篇关于当另一个DLL中的一个DLL给用户断点命中时，Win 10上的VC6调试的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
