调试 Windows 服务并尝试查看它所看到的内容 [英] Debugging a Windows Service and trying to see what it sees

问题描述

我们目前有一个自动化系统，作为处理卫星图像的服务运行.该服务维护一个配置文件，在配置文件中我们应用某些脚本(python)将输入的卫星图像转换为更可用的格式.脚本调用所需的应用程序，用于转换过程.脚本本身由服务通过 system("command")(用 c/c++ 编写)调用.(该服务使用与用户相同的帐户).

We currently have an automated system that runs as a service for processing satellite images. This service maintains a configuration file, in the configuration file we apply certain scripts(python) to covnert the input satellite imagery into a more usable format. The scripts call the required applications, for the conversion proces. The scripts themselves are invoked by the service via the system("command") (its written in c/c++). (the service uses the same account as the user).

我们目前正在尝试添加对另一种卫星图像格式的支持，转换器是来自 ERDAS Imagine(importavhrr) 的商业 .exe，(我们在脚本中执行了几个自己的步骤来更改投影).

We currently are trying to add support for another satelitte imagery format, the converter is a commerical .exe from ERDAS Imagine(importavhrr), (we do several of our own steps after in the script to change the projection).

脚本工作正常，直到它遇到这个:

The script works fine, up until it hits this:

argslist = ['importavhrr.exe', '-in', '%s' % infn, '-out', '%s' % tmpimg1, '-gui', 'FALSE', '-correct', '-flyingheight', '833', '-rect', 'gcp', gcpfn]
print "".join(argslist)
p = subprocess.Popen(argslist, shell=True, stderr=subprocess.PIPE, stdout=subprocess.PIPE)
print str(p.communicate())

现在最终发生的是，importavhrr.exe 只是坐在那里，什么也不做(根据任务管理器，它使用 0 cpu 使用率坐在那里，并且内存使用率永远不会改变).好像它在等待某种用户输入.(尝试 os.system 和 os.spawnv 都产生相同的结果)我猜测某种 gui 元素会弹出一个 gui 窗口.从任务管理器关闭进程，将控制权返回给 python.

What ends up happening now is, importavhrr.exe just sits there, and does nothing(according to taskmanager it sits there using 0 cpu usage, and the memory usage never changes). As if its waiting for some sort of user input. (Trying os.system, os.spawnv both yield same results) I am guessing some sort of gui element is ether popping up with a gui window of sorts. Closing the process from task manager, returns control to python.

注意: -gui FALSE/false/0 参数应该是为了防止 gui 弹出.但是，如果数据不好(我通过破坏数据并通过脚本调用来手动测试)，则会弹出一个错误窗口，显示结果.

Note: The -gui FALSE/false/0 argument is supposed to prevent a gui from poping up. However if the data is bad (i tested this manually by corrupting the data, and invoking via a script) an error window will popup showing the results.

当我手动运行脚本(相同的文件，相同的工作目录)时，它工作正常......当我使用与服务相同的系统功能(它的内部库的一部分)手动调用它时，脚本甚至可以工作.

When i run the script manually (same file, same working directory), it works fine.... the script even works when i invoke it manually using the same system function (its part of an inhouse library) as the service.

还使服务仅使用 importavhrr.exe 和环境变量调用批处理文件也会导致 importavhrr.exe 挂起.

Also making the service invoke a batch file with just the importavhrr.exe and the enviroment variables also results in the importavhrr.exe hanging.

服务横向:- 使用与我登录时相同的用户帐户- python 脚本为 ERDAS 设置了大约 30-40 个环境变量- 所有环境变量都已正确设置(在第一次运行脚本时转储环境变量，并将它们与我打印消息时得到的内容进行比较)- 将环境变量传递到 subprocess.Popen() 产生相同的结果- 该公司拒绝帮助我们，因为他们不支持从命令行运行程序(但是当用户这样做时它可以正常工作，只是不是服务)- 在调试模式下运行服务工作正常.- 我已经重新启动了机器.

Service Sidewise: - Uses the same user account as the one i logged in with - The python script sets around 30-40 envrioment variables for ERDAS - All the enviroment variables are properly set(dumping the enviroment variables when the script is first run, and comparing them to what i get when i print the messages) - Passing the enviroment variables into the subprocess.Popen() yields the same results - The company refuses to help us because they don't support running programs from command line (however it works fine when a user does it, just not a service) - Running the service in debug mode works fine. - I HAVE rebooted the machine.

我在这里不知所措，我认为(并担心)ERDAS 可执行文件正在弹出某种错误消息窗口，但是我已经看过了，并且找不到任何方法来查看服务见.我已经尝试解决这个问题将近一个星期了，所以是的.

I am at a loss here, i think (and fear) that the ERDAS executable is making some sort of error message window popup, however i have looked, and looked and can't find any sort of way to see what the service sees. I have been trying to figure this out for almost a week now so yeah.

编辑

我抓住了推荐的 Process Explorer，并查看了我拥有的堆栈线程:

I grabbed the recommended Process Explorer, and looking at the stack thread i have this:

<snip ntoskrnl calls>
ntdll.dll!KiFastSystemCallRet
ntdll.dll!RtlSetLastWin32ErrorAndNtStatusFromNtStatus+0x301
kernel32.dll!GetModuleHandleA+0xdf

等待几分钟后，它变成了这样:

After waiting a few minutes, it changes to this:

<snip ntoskrnl calls>
ntdll.dll!KiFastSystemCallRet
USER32.dll!ScrollWindowEx+0x121d
USER32.dll!SoftModalMessageBox+0x6f8
USER32.dll!MessageBoxTimeoutW+0x1d9
USER32.dll!MessageBoxTimeoutW+0x5b
USER32.dll!MessageBoxTimeoutA+0x9c
USER32.dll!MessageBoxExA+0x1b
USER32.dll!MessageBoxA+0x45
elib.dll!esmg_GetLocalTapesDB+0x23b
elib.dll!esmg_LogMessageFunc+0x13a

好吧，我想它正试图显示一个窗口.我对他们的行为一无所知，以查看可能导致 esmg_LogMessageFunc 崩溃的原因.该功能是他们开发工具的一部分，我有 0 访问权限.此外，我从未真正见过 erdas 记录任何内容.

Well it is trying to show a window, i presume. I don't know anything about their behaviour to see what could be causing esmg_LogMessageFunc to crash. That function is part of their dev tools, which i have 0 access to. Furthermore i have never actually seen erdas log anything.

推荐答案

尝试使用任何假定访问 windowstation 的 Windows API 调用都会导致服务的安全上下文出现问题.

Trying to use any Windows API calls that assume access to the windowstation will cause problems in the security context of a service.

您可以使用 Sysinternals 中的多种工具来诊断此问题之类的事情.具体来说，请考虑使用 Process Explorer 代替任务管理器，并且 进程监视器，用于跟踪特定进程的活动.

You can use several of the tools from Sysinternals to diagnose this kind of thing. Specifically, consider using Process Explorer in place of Task Manager, and Process Monitor for tracing the activity of a specific process.

他们的新ProcDump工具可用于获取具有真正强大触发功能的任何进程的核心转储.Mark Russinovich 的博客 上的几个最新战争故事利用 ProcDump发现到底发生了什么.

Their new ProcDump tool can be used to get a core dump of any process with really powerful triggering. Several of the latest war stories on Mark Russinovich's Blog take advantage of ProcDump to discover what really happened.

为完整起见，这篇知识库文章.

这篇关于调试 Windows 服务并尝试查看它所看到的内容的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！