我正在尝试解决非托管C ++应用程序上的崩溃/异常。
应用程序崩溃时具有一定的可预测性。该计划基本上 处理大量文件并运行一堆查询 访问DB。
在文件访问期间肯定会发生这种情况。错误消息是：
"failed reading. Network name is no longer available."
它似乎总是在同一个较低级别的文件访问代码中崩溃。 它正在做一个较低级别的库Seek（），然后是一个Read（）。发生异常 在阅读期间。
为了使事情进一步复杂化，我们只能在发生错误时才会发生错误 我们正在运行磁盘平衡实用程序。该实用程序基本上检查文件 访问历史记录并将更频繁/最近使用的文件移动到更快的存储检索 而较少使用的文件会移动到较慢的检索区域。我不完全 了解这个特定存储设备的架构， 但基本上它有一个“快速”检索区域和一个“存档/慢速”区域。
启动实用程序应用程序时，问题更容易/可预测地重现 停了好几次。根据磁盘制造商的说法，我们应该能够运行 后台实用程序，不会影响客户端主应用程序的行为。
有任何建议如何在这里进行？这里有一些理论浮出水面，它与存储设备上的延迟有某种关系。有没有办法证明/反驳这一点？我们编写了一个小样本应用程序，它基本上可以访问/读取驱动器上的大量文件。我们（到目前为止）甚至无法重现与SmartPools一起运行的问题。我的想法是尝试推动延迟理论是让多个应用程序在运行实用程序应用程序时基本上从磁盘读取大量文件。
内存使用情况和CPU使用率在任务管理器中看起来不合适。
思考？这变成了一个毛球。
谢谢， JohnB
答案 0 :(得分：0)
抓住你的调试二进制文件。 设置Application Verifier并将您的应用程序添加到其列表中。 希望等待崩溃愚蠢。 把它通过WinDBG。 尝试命令：！avrf 看看你得到了什么......