Waiting for a program
Waiting for a program is essentially the same as injection except that instead of injecting into a running program, Performance Validator watches for the process starting up and then injects.
If the process is a service, Performance 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 Performance Validator in administrator mode.
If the application you want to wait for is running with Administrator privileges, Performance Validator will also need to run with Administrator privileges.
When choosing the 'wait for program' method described in this topic, a restart of Performance Validator with administrator privileges will be required to proceed.
Waiting for a service?
If your process is a service, Performance 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.
•Collect function times tick to collect data that will allow overall function timings to be calculated
•Collect line times tick to allow individual line timings to be calculated
A warning dialog may be displayed to remind you of the possible performance slowdown when using line timing.
This warning only appears if the Enable line timing warning option on the Performance settings is checked.
The option at the bottom to edit line timing filters can be used to set specific classes, methods and functions to be included in, or excluded from, the hooking process and is identical to the Line Timing Filters page of the global settings dialog.
Unchecking function and line times means not collecting any data at all!
•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 Performance 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 Performance Validator into the specified process, showing progress status
•Stop Waiting stops the wait
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)
