鼠标光标在 Windows LabView 中冻结
我正在 Windows 上的 LabView 中开发一个应用程序。从一周前开始，一台测试机（至少是一台 ToughBook）每隔几天就会完全死机：没有鼠标光标，任务栏时钟冻结。所以昨天就退役了。但刚才，我在另一台机器上看到了它，也是一台笔记本电脑。
对于 PC 来说，这是一种非常罕见的故障模式。我对Windows了解不多，但我希望它能表明该软件突然完全停止运行，以至于内核无法恐慌。
这是一个准确的评估吗？我从哪里开始调试这个问题？在 Windows 体系结构中，是什么控制着光标——是所有内核模式还是有一个窗口服务器可能会被某些东西阻塞？是否是不稳定的第三方硬件驱动程序导致了这种情况，而不是蓝屏？
编辑：我应该补充一点，冻结不一定在代码运行时发生。
I'm developing an application in LabView on Windows. Starting a week ago, one test machine (a ToughBook, no less) was freezing up completely once every couple days: no mouse cursor, taskbar clock frozen. So yesterday it was retired. But just now, I've seen it on another machine, also a laptop.
This is a pretty uncommon failure mode for PC's. I don't know much about Windows, but I'd expect it to indicate that the software stopped running so completely and suddenly that the kernel was unable to panic.
Is this an accurate assessment? Where do I begin to debug this problem? What controls the cursor in the Windows architecture — is it all kernel mode or is there a window server that might be getting choked by something? Would an unstable third-party hardware driver cause this, rather than a blue screen?
EDIT: I should add that the freezes don't necessarily happen while the code is running.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
我当然会考虑硬件和/或驱动程序作为一种可能性 - 也许你可以说涉及哪些硬件？
您可以通过为 LabVIEW 代码所涉及的每个硬件添加“调试模式”来测试这一点，您可以使用例如案例结构来跳过实际的 I/O 调用并将虚拟数据返回到应用程序的其余部分。确保其数据量与真实设备返回的数据量相似。如果您将代码模块化为具有明确定义功能的子VI，您会发现这要容易得多！如果禁用对特定硬件位的 I/O 调用可以停止冻结，则表明问题可能出在该硬件或其驱动程序上。
I'd certainly consider hardware and/or drivers as a possibility - perhaps you could say what hardware is involved?
You could test this by adding a 'debug mode' for each piece of hardware your LabVIEW code talks to, where you would use e.g. a case structure to skip the actual I/O calls and return dummy data to the rest of the application. Make sure it's a similar amount of data to what the real device returns. You'll find this much easier if you've modularised your code into subVI's with clearly defined functions! If disabling I/O calls to a particular bit of hardware stops the freezes it would suggest the problem might be with that hardware or its driver.
很难说问题是什么。根据症状，我会检查是否存在内存泄漏（使用“Windows 任务管理器”查看您的 LabVIEW 应用程序内存使用量是否随时间增加）。
Hard to say what the problem is. Base on the symptoms I would check for a possible memory leak (see if your LabVIEW app memory usage is growing overtime using "windows task manager").