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:
or click on the Wait (timer) icon on the session toolbar.
or use the shortcut
Wait for application
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 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.
•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.
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.
This must be the full path to the DLL. For example test.dll or 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.
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.
.Net Core (Framework-dependent)
.Net Core (Self-contained)