Assertion failure: "(!"SetThreadContext failed")"问题的解决办法

最新推荐文章于 2024-01-16 16:49:45 发布

原创最新推荐文章于 2024-01-16 16:49:45 发布 · 6.5k 阅读

2 ·

本内容遵循CC 4.0 BY-SA版权协议

收录于

Delphi

在编译程序并运行后，Delphi2007会提示以下错误(windows 7 64位运行环境)：

---------------------------
bds.exe - bordbk105N.dll
---------------------------
Assertion failure: "(!"SetThreadContext failed")"
in ..\win32src\thread32.cpp at line 412
Continue execution?

---------------------------
Yes No
---------------------------

———————华丽的分割线————————-

Delphi 2007 或 2009 在 Windows 7 x64 以及其他 x64 系统下，退出 IDE 时，调试器会产生一个断言错误。

错误窗口标题为：bds.exe – bordbk120N.dll，内容为：Assertion failure: “(!”SetThreadContext failed”)” in ..\win32src\thread32.cpp at line 434。

解决办法是使用一个非官方的补丁程序进行修复。

补丁程序来源：http://www.monien.net/blog/index.php/2009/07/delphi-2009-windows-7-64-bit-debugger-crash-workaround/

Delphi 2009 / Windows 7 / 64 bit Debugger Crash Workaround

Yesterday I revisited a nasty problem that occurs on Windows 64bit versions. I ran into that when I upgraded to Windows 7, but it seems it affects older 64bit editions of Windows as well.

After installing D2009 on a clean Win7 machine I was happy to see that Windows 7 really is what Vista should have been. It works snappy and has a lot of productivity features. But then when I started compiling and debugging a couple of my existing Delphi applications I experienced Debugger crashes almost everytime when I terminated an application.

Unfortunately no matter if you press “Yes” or “No” on that screen – you have to restart the whole Delphi IDE – which basically makes debugging impossible. In some (actually many) cases you even have to terminate Delphi using Windows TaskManager. I tried all of the compatibility settings Win7 offers, as well as running Delphi as Administrator – but no luck.

Some research on Google, QC and RAID showed that similar exceptions were reported with older Delphi versions, but apparently only on 64bit Windows editions. As the message already suggests, the problem appears to be an invalid call to a SetThreadContext API call. Some tests showed that you can easily reproduce this issue once you have more that just a single thread in your Delphi application. As you might know, I am doing quite a lot of Web application server development – which by nature create many threads…

I created a RAID entry for that (actually an existing one was updated with detailed reproduction steps – iirc) and joined a discussion thread on that topic to see if others are reporting that too. Because of time constraints I did not revisit that issue over the last couple of weeks, but yesterday when I was talking to Daniel Magin, we together found a solution someone had posted on a German Forum a few weeks ago. The original idea is from an MS TechNet posting though (credits go to a guy called Xelax Ax).

He posted a workaround that basically disables the check for a possible error returned by SetThreadContext, i.e. the debugger ignores the error and does not crash because of the Assert that checks fro no error returned. As Andreas Hausladen already correctly mentioned, this is really just kind of a weak workaround, because the debugger might misbehave after that and we just do not know why SetThreadContext fails at all. The point is though that with this fix I can work effectively again with D2009 on Win7/64bit and as this error only happens when the debugger is about to shout down anyway, so the danger of unwanted side effects is not too high imho.

Be careful! No waranties! I am not responsible for lost files etc.! Back up first!

Workaround steps:

Close Delphi
Locate bordbk120N.dll (C:\Program Files (x86)\CodeGear\RAD Studio\6.0\bin)
Make a backup copy
Check step 3
Open bordbk120N.dll in a Hex editor (UltraEdit works fine)
Search for “01 00 48 74 47 80 3D”
Make sure this is found once only
Replace “74” with “EB”
Save
Restart Delphi. Error should be gone.

This might work on older Delphi versions as well, but I did not test that yet.

Update 1

I talked to some CodeGear Q&A guy and he tested their current internal Weaver build under the conditions where D2009 fails. The good news is that the error seems to be gone there – so the next Delphi Version will probably be good. For those who want to get started now: please see Update 2 below.