1

What's a good robust way to query processes for their help or framework origin, especially in Windows?

I've got an automated testing module that queries binaries that fit a special name pattern with --help to see what test framework, if any, was used to compile that test binary, so it can give it special command treatment depending on the test mode's objective.

The problem is that since it won't be only used by me, I anticipate that binaries that require manual interaction before they quit will be triggered for Murphy's law and subsequently fail to exit on their own.

I'd prefer my module to be robust enough to handle this scenario, so I thought about launching that process within another process, getting its PID, and setting up some kind of observer pattern to meaningfully monitor it over time or events triggered, whichever first.

I anticipate no problems with that, which worries me :) I feel like I'm missing an important currently nebulous corner-case. I also wonder if there's a better way to check binaries for their framework origins used than doing --help queries to search for framework help message output patterns.

I'd really like to skip the whole, running binaries blindly to figure out what kind of test binary they are, step, but I don't know if I can do this reliably, dynamically, in a generic approach.

So,

  1. Can a binary's origin, if created within a framework, be somehow detected in a non-framework-specific way besides a help query? That includes common approaches that aren't necessarily universally embraced, or common approaches doled out by each framework in an easy way; meaning, I could make a handful of small modules for supported frameworks that are known. (answered in comments)
  2. If I use a dedicated process to check the status of a process that I've launched, can I safely handle all spawned process responses? Crashes, unresponsiveness, etc, stuff like that. For example, if a missing DLL triggering an error-pop-up even when launched from command-line.
Improve this question
13
  • 1
    How about just kill the process after 5 seconds? Commented Apr 27, 2017 at 0:10
  • Are os-level kill / taskkill commands guaranteed to nuke the process regardless of its state? If so, that would be a viable approach for #2. Commented Apr 27, 2017 at 0:15
  • 1
    Can't you just check which dependencies the binaries have? See here, stackoverflow.com/questions/7378959/…, the second answer from the top, suggesting dumpbin /dependents? Commented Apr 27, 2017 at 17:49
  • 2
    @kayleeFrye_onDeck: well, you did not tell us so far what kind of license requirements you have. But if this is for a program you want to distribute to a third party, you are probably correct, I guess Microsoft does not seem to allow the distribution. If Google does not help, maybe you can ask on softwarerecs.stackexchange.com if there is a similar tool with different license terms. Commented Apr 27, 2017 at 21:31
  • 1
    ... another alternative is Dependency walker, which is free and has a command like mode, see dependencywalker.com Commented Apr 27, 2017 at 21:38

1 Answer 1

Reset to default
1

OP here, an update addressing the question:

  1. You can detect some dependencies for some test frameworks, depending on how the binary was built and linked to. The only information you can get from the binary without loading and exercising it is this thing called the Import Table, aka Static Import Table, not to be confused with the Import Address Table, which changes once the image loads. You're not going to get the DLLs loaded by the process via Win32 APIs like LoadProcess, so mileage will vary.

For example, if I build my tool with just calling the VCVARS batch and running cl.exe source.cpp /EHsc, it's going to give me very different dependency information than if I say, make the same exact Visual C++ Empty Project that incorporates all the helper configurations from projName.vcxproj

For .NET assemblies, I made a lean-and-mean console-app to detect .NET Assemblies used for .NET test frameworks. It's source is available to view on SO here: https://stackoverflow.com/a/43669672/3543437

  1. Not all corner-cases can be guaranteed but most can be overcome when you both have admin privs and use taskkill to the process tree by process ID. I've found doing system calls like taskkill /F /T /PID %PID%and checking its error code is a perfectly suitable replacement for a programmatic way to nuke a process not responding desirably

To achieve my overall goal for this question, I made two C++ modules;

The first was a command-line utility to parse and read off the PE COFF Import Table's dependency names, like dumpbin and link can do, using error codes to help determine if there were dependencies or not, so tools like findstr can be leveraged. I'm looking forward to using ldd instead of porting this sucker... it was a long and painful process due to how low-level and obscure it was. I basically had to re-learn low-level memory management, so that was actually a good thing.

The second was a command-line utility that took a process name/location, one argument for how long it could last for in milliseconds, and one for how often to poll it in milliseconds; then an additional optional argument to take a double-quote surrounded list of parameters. The kill-timer is absolute, but I coded it so exit-codes let you know how the process ended. All by checking exit codes, it lets you know if: * Process exited on its own, non-zero * Process exited on its on, zero * Process had to be force-killed * Process failed to launch * User queried the help

Which covers all the cases I could think of at the time.

Overall this process took a lot longer than expected, due to dealing with the PE COFF stuff. If you find yourself in similar shoes, see if you can find an open source project that uses a stack that plays well with yours.

I also found the following resources really helpful when trying to understand the PE COFF:

A. Visualization of the PECOFF File Format
B. X86 Dissassembly Breakdown
C. Executable File Analysis (Windows Forensic Analysis) Part 2

Honorable mention that might cause you headaches due to being dated:

D. Peering Inside the PE: A Tour of the Win32 Portable Executable File Format by Matt Pietrek, March 1994, Microsoft Systems Journal

Improve this answer

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.