sqlnclir.rll 不断加载和卸载
我正在一个与 SQL Server 2000 通信的 C++ 应用程序中使用 SQL Native Client 9。我现在正在调试一些东西，但我注意到让我烦恼的事情（主要是因为它造成了严重的混乱）是 sqlnclir。 rll 正在不断加载和卸载，并且以下几行被垃圾邮件发送到我的调试输出窗口。
'my_app.exe'：已加载'C:\WINDOWS\system32\sqlnclir.rll'，二进制文件不是使用调试信息构建的。 线程“Win32 Thread”(0x9f4) 已退出，代码为 0 (0x0)。 “my_app.exe”：已卸载“C:\WINDOWS\system32\sqlnclir.rll”
“Win32 Thread”后面的ID发生变化，但退出代码始终为0。
为什么.rll会像这样不断地被加载和卸载，如何防止这种情况发生？
如果上述问题无法回答，如何防止上述消息被垃圾邮件发送到 MSVC 2005 中的“调试输出”窗口？ 理想情况下，仅针对特定的一组消息？
I'm working with SQL Native Client 9 in a C++ application that communicates with SQL Server 2000. I'm working on debugging things right now but something I've noticed that bothers me (mostly because it's creating significant clutter) is that sqlnclir.rll is being loaded and unloaded continuously and the following lines are being spammed to my debug output window.
'my_app.exe': Loaded 'C:\WINDOWS\system32\sqlnclir.rll', Binary was not built with debug information. The thread 'Win32 Thread' (0x9f4) has exited with code 0 (0x0). 'my_app.exe': Unloaded 'C:\WINDOWS\system32\sqlnclir.rll'
The ID after "Win32 Thread" changes but the exit code is always 0.
Why is the .rll is being loaded and unloaded constantly like this and how can I prevent it from happening?
If the above isn't a feasible question to answer, how can I prevent the messages above from being spammed to the Debug Output window in MSVC 2005? Ideally, only for that particular set of messages?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
通常，这是由于应用程序（或在本例中为链接库）通过 LoadLibrary[Ex] 等动态加载和卸载。它可能还在进程中创建/销毁线程。
我不知道有什么方法可以抑制各个调试输出消息。 您可以通过自己加载库并在调用期间持有它的句柄（这应该防止操作系统卸载它）来防止特定的重复加载/卸载。 然而，这不是一个好的通用解决方案（例如，库可能被编码得[糟糕]，依赖于每次调用之间未初始化的 DLL，在这种情况下，解决方法可能会改变行为）。
在更高的级别上，保持与数据库的连接打开可能会完成同样的事情，但这取决于 SQL 本机客户端库的实现。 不过，这就是我可能会尝试的方法（或者只是忽略调试跟踪输出）。
Typically this is due to the application (or in this case, a linked library) dynamically loading and unloading via LoadLibrary[Ex] etc. It is probably also creating/destroying a thread in the process.
I don't know of any way to suppress individual debug output messages. You may be able to prevent the specific repeated load/unload by loading the library yourself and holding a handle to it for the duration of the calls (which should prevent the OS from unloading it). However, this is not a good general solution (for example, the library might be [poorly] coded to rely on the DLL being uninitialized between each call, in which case the workaround might alter the behavior).
At a higher level, keeping a connection open to the database might accomplish the same thing, but that's dependent on the implementation of the SQL native client library. That's what I would probably try, though (or just ignore the debug trace output).