Waiting for a program

 

Waiting for a program is essentially the same as injection except that instead of injecting into a running program, Memory Validator watches for the process starting up and then injects.

 

If the process is a service, Memory Validator won't be able to attach to it as services can't have process handles opened by third party applications, even with Administrator privileges.

 

Choose one of these methods of waiting:

 

Launch menu Applications Wait for Application... shows the Wait for application wizard or dialog below

 

or click on the Wait (timer) icon on the session toolbar.

 

 

 

or use the shortcut

 

   Wait for application

 

 

Administrator privileges

 

The following applies only if you did not start Memory Validator in administrator mode.

 

If the application you want to wait for is running with Administrator privileges, Memory Validator will also need to run with Administrator privileges.

 

When choosing the 'wait for program' method described in this topic, a restart of Memory Validator with administrator privileges will be required to proceed.

 

 

 

Waiting for a service?

 

If your process is a service, Memory Validator won't be able to attach to it.

 

Services can't have process handles opened by third party applications, even with Administrator privileges.

 

In order to work with services, you can use the NT service API and monitor the service

 

 

The wait for application dialog

 

The wait for application dialog lets you specify the application or choose one that you've waited for previously.

 

 

 

•Collect data from application do want to collect data from the instant you attach to the application?

 

Depending on your application, and what you want to validate, you may want to start collecting data as soon as injection has happened, or do it later.

 

If your program has a complex start-up procedure, initialising lots of data, it may be much faster not to collect data until the program has launched.

 

If it's the startup procedure you want to validate, obviously start collecting data from launch.

 

See the section on controlling data collection for how to turn collection on and off after launch.

 

•Application Path Policy specify how the specified executable is treated

 

oPath to executable exists the executable will be checked that it exists and is appropriate for Memory Validator to work with

 

oPath to executable is created dynamically most pre-wait checks are not performed - use this if the path the executable is on does not exist at the time you start waiting for the process to start

 

•Application type choose the type of application

 

oNative and .Net

o.Net Core (Framework Dependent)

o.Net Core (Self Contained)

 

•Application Executable edit or Browse... the application to wait to start.

 

The name of the executable. For example c:\unitTests\test.exe or test.exe.

 

If Application Path Policy is Path to executable exists this must be the full path to the executable. For example c:\unitTests\test.exe.

 

For native applications this is the application executable.

 

For .Net Framework applications this is the application executable.

 

For .Net Core Framework-dependent applications this is most likely going to be c:\program files\dotnet\dotnet.exe.

 

For .Net Core Self-contained applications this is the application executable.

 

•Application DLL edit or Browse... the application DLL to wait to start. This field is only needed for .Net Core applications.

 

The name of the DLL. For example c:\unitTests\test.dll or test.dll.

 

If Application Path Policy is Path to executable exists this must be the full path to the dll. For example c:\unitTests\test.dll.

 

For native applications this is not used.

 

For .Net Framework applications this is not used.

 

For .Net Core Framework-dependent applications this is the application dll. (the name of the dll that you would pass to dotnet.exe on the command line).

 

For .Net Core Self-contained applications this is the dll that has the same name as the application executable. (for theApp.exe, the dll name is theApp.dll).

 

•Full path shows the full path to the process executable in the list
 

•Image Name shows the short program name without path

 

•Reset clears the list

 

•Wait for Process... starts waiting and then injects Memory Validator into the specified process, showing progress status

 

•Stop Waiting stops the wait

 

 

If your program is linked statically to the C runtime libraries, you might want to read the topic before you start.

 

What could go wrong?

 

The program you're waiting for might already be running, in which case you'll be given the option to cancel or attach to the existing process:

 

 

Timing issues are inherit with native injecting into a program as it starts up.

 

This could cause the injection to fail in unpredictable ways and you may see dialogs like that below:

 

 

One case when this dialog can occur is if the program needs to run at an elevated privilege and is waiting for the user to give permission via the UAC dialog.

 

Injection may fail for different reasons and you might see the following information dialog showing:

 

•messages relating to the specific failure

•a selection of reasons why failure might be occurring

•some possible solutions to the problem

 

 

Sometimes retrying a few times might catch a better moment for attaching to the process.

 

In the general questions see Why might Inject or Launch fail? for troubleshooting launch problems.

 

 

 

Example Dialogs

 

Native

 

 

 

.Net

 

 

.Net Core (Framework-dependent)

 

 

.Net Core (Self-contained)