从 Java 程序中调用外部可执行文件的令人困惑的失败
好吧，我遇到了一个错误，它让我感到困惑。我正在寻找关于我可以调查什么的想法，因为现在我什么也没得到。事情是这样的：
我有一个独立的 Java 应用程序，偶尔需要调整它运行的计算机（WinXP 计算机）的线路输入音量。它通过调用一对可以获取和设置各种组件卷的外部可执行文件（用 VB6* 编写）来实现此目的。 （它们可以处理线路输入、麦克风、Wave、CD 和主音量控制。）
现场有数百台设备，在我公司提供和控制的硬件（戴尔机器）上运行。至少有几十个客户正在使用这一功能，而且它运行得很好——除了一个实例。
对于这台制造麻烦的机器来说，它根本不起作用。当应用程序运行时，我会观察音量滑块，当音量应该下降时，它们会保持原状。当我检查应用程序的日志文件时，它没有抛出任何错误，并且似乎正在执行降低音量的代码。当我从命令行运行可执行文件时，它们工作得很好。
我不能保证这台机器与所有运行正常的机器 100% 相同，但我们已经购买同一系列的戴尔机器相当长一段时间了；至少，它非常非常相似。
所以，把我的困惑变成一个项目符号列表：
- 如果我在 Java 代码中做了一些愚蠢的事情（即，没有清除我的 STDOUT/STDERR 缓冲区），为什么这只是这台机器上的问题？
- 如果 VB6 可执行文件中存在某些问题，为什么它们可以通过命令行在所有其他计算机上和在本计算机上运行？
- 如果这台机器上存在某种硬件异常，那么什么样的异常可能导致音量控制可执行文件仅在从 Java 应用程序内调用时失败？
我很困惑。我不喜欢感到困惑。有人有任何建议可能会启发我吗？ **
-* -- 我知道，我知道，VB6，1998 被调用，他们希望他们过时的专有错误生成器回来，等等。这不是我的决定。但代码有效。通常。
-** -- 在此插入佛教笑话。
更新编辑：客户服务可能偶然发现了一些事情；这可能与数据库中的客户端配置设置有关。新的证据表明，要么该客户端的某些配置错误，要么我的软件在响应特定配置时做了一些愚蠢的事情。而且这个问题可能比我们想象的更广泛，因为这个特殊的功能并不像我想象的那么常用。
回复评论：
- 调试器：理论上是可行的，但考虑到我们的设置，看起来非常令人头疼。
- 高详细日志记录，Java：这是个好主意，特别是考虑到问题可能比我最初认为的更广泛。是时候开始重新审视一些假设了。并可能用棍棒打他们。就像海豹宝宝一样。
- 高详细日志记录，VB6：一种可能性；需要将其合并到详细的 Java 日志记录中以捕获输出，因为我的 VB6-fu 非常弱，我不知道如何将文本输出到文件。但是，是的，知道脚本是否被调用是很有价值的。
- Window Event Viewer：不熟悉这个工具。可能必须纠正这一点。
- 路径问题：感觉不太可能； Java 代码构造了可执行文件的相对路径，该路径看起来并不依赖于任何环境变量。
我感谢人们提供的建议；至少，你让我的大脑朝着有希望的方向发展。
解决方案编辑：获胜者是...这不是错误，这是功能！一个功能出现了严重错误。现在该功能将被阉割，以便不再打扰我们。
一批无效的假设使我无法更快地看到它，其中最重要的是“我不需要使用更多调试语句来处理代码 - 已经存在的语句告诉我我需要知道的一切！” DaDaDom，如果您想将您的评论变成答案，里面有一个闪亮的复选标记适合您。
感谢所有提出建议的人。现在请原谅，我和办公桌开会迟到了。
All right, I've hit a bug that has simply confused the bejeebus out of me. I'm looking for ideas about what it could be that I can investigate, because right now, I got nothing. It goes something like this:
I have a standalone Java application that occasionally needs to twiddle the Line-In volume of the computer it's running on (a WinXP machine). It does this by calling a pair of external executables (written in VB6*) that can get and set various component volumes. (They can handle Line-In, Mic, Wave, CD, and the master volume control.)
There are several hundred units in the field, running on hardware (Dell machines) that my company provided and controls. At least several dozen clients are using this feature, and it works perfectly -- except for one instance.
For this one troublemaking machine, it simply doesn't work. I watch the volume sliders when the app is running, and when the volume is supposed to drop, they stay put. When I check the app's log file, it throws no errors, and appears to be executing the code that drops the volume. When I run the executables from the command line, they work perfectly.
I can't vouch for this machine being 100% identical to all the ones that are behaving properly, but we've been buying the same line of Dells for quite some time now; at a bare minimum, it's very, very similar.
So, turning my confusion into a bullet list:
- If I'm doing something stupid in the Java code (i.e., not clearing my STDOUT/STDERR buffers), why is it only an issue on this machine?
- If there's something broken in the VB6 executables, why do they work on every other machine and on this machine from the command line?
- If there's some sort of hardware oddity on this machine, what sort of oddity could cause the volume control executables to fail only when called from within a Java application?
I am very confused. I do not like being confused. Anybody have any suggestions that may lead to my enlightenment?**
-* -- I know, I know, VB6, 1998 called and they want their obsolescent proprietary bug generator back, etc. Wasn't my decision. But the code works. Usually.
-** -- Insert Buddhism joke here.
Update Edit: Customer service may have stumbled onto something; it may be something to do with client configuration settings in the database. New evidence suggests that either something's misconfigured for that client or my software is doing something stupid in response to a specific configuration. And the problem may be more widespread than we thought, due to this particular feature not being as commonly used as I thought.
Responding to the comments:
- Debugger: Theoretically possible, but looks like a massive headache given our setup.
- High Verbosity Logging, Java: Good idea this, particularly given than the problem may be more widespread than I originally believed. Time to start revisiting some assumptions. And possibly clubbing them. Like baby seals.
- High Verbosity Logging, VB6: A possibility; will need to be rolled-into the high-verbosity Java logging to trap the output, since my VB6-fu is so pitiably weak I don't know how to output text to a file. But, yeah, knowing whether or not the script is even getting called would be valuable.
- Window Event Viewer: Not familiar with this tool. May have to correct that.
- PATH problem: Doesn't feel likely; the Java code constructs a relative path to the executable that doesn't look like it's relying on any environment variables.
My thanks for the suggestions people have provided; at the very least, you've gotten my brain moving in directions that feel promising.
Solution Edit: And the winner is ... That's Not A Bug, That's A Feature! A feature gone horribly, horribly wrong. A feature that will now be neutered so as to stop bothering us.
A batch of invalid assumptions kept me from seeing it sooner, not the least of which was "I don't need to tool the code with more debug statements -- the statements already in there are telling me all I need to know!" DaDaDom, if you'd like to turn your comment into an answer, there's a shiny checkmark in it for you.
Thanks to everybody who chimed in with a suggestion. Now if you'll excuse me, my head is late for a meeting with my desk.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
这是一个答案：
您可以创建具有详细日志记录的软件版本，或者甚至可以调试代码吗？至少你可以判断它是在java还是VB部分。
Here goes an answer:
Can you create a version of the software with verbose logging or could you even debug the code? At least then you can tell if it's in the java or the VB part.
嗯嗯。有人告诉我，从 Java 执行程序要么容易，要么困难。最简单的部分是启动它们。困难的部分是处理 I/O 流（请参阅 我之前关于使用 Runtime.exec 的问题（ ））。也许 VB 程序正在这些特定机器上执行或期望执行一些奇怪的操作，而 Java 代码无法正常工作。
编辑：我还找到了 Jakarta Commons Exec 的链接：
Hmmmm. I've been told that executing programs from Java is either easy or hard. The easy part is starting them up. The hard part is dealing with the I/O streams (see my earlier question on using Runtime.exec()). Maybe the VB program is doing or expecting something weird on these particular machines that the Java code isn't working with properly.
edit: I also found a link to Jakarta Commons Exec:
您是否考虑过经过身份验证的用户可能无权编辑工作站上的卷设置的可能性？如果您以“管理员”身份运行，程序是否可以正确运行？
Have you considered the possibility that the authenticated user may not have permission to edit volume settings on the workstation? Does the program run correctly if you run as an 'Administrator'?