This field can be filled in with any arguments you wish to start the application with.

This field contains the directory that the application should start in. By default, this field is filled in with the directory that the main executable lives in. If you wish to change this directory, you can type in a new directory or press the Browse button to graphically choose a new directory. You can also press the Default button to restore this field to its default directory.

This button will display a browse dialog that lets you graphically choose a starting directory for the application. After you choose a directory, it will appear in the Starting Directory field.

This button will restore the Starting Directory field to its default directory.

When this box is checked, the Log View will be cleared before the profile is started.

When this box is checked, Dependency Walker will simulate the ShellExecute function when starting your application. This ensures that your application's "App Paths" entries are part of the search path. When this box is not checked, Dependency Walker simply calls CreateProcess to start your application, which does not use the "App Paths" entries. Usually, you should check this box unless you are troubleshooting a problem related to "App Paths" entries.

Dependency Walker monitors all calls to each non-shared module's entrypoint, usually known as the DllMain function. When this box is checked, all DllMain functions called with the DLL_PROCESS_ATTACH message or DLL_PROCESS_DETACH message will be logged. If a module returns 0 from its DllMain function while processing the DLL_PROCESS_ATTACH message, then the OS will unload the module and return a failure. In the case of an implicit dependency, this will cause the entire application to fail to load with an error dialog reading something like "The application failed to initialize properly". In the case of a dynamic dependency, the call to LoadLibrary will fail with error 1114 (ERROR_DLL_INIT_FAILED), but the application may continue to run.

Dependency Walker monitors all calls to each non-shared module's entrypoint, usually known as the DllMain function. When this box is checked, all DllMain functions called with the DLL_THREAD_ATTACH message or DLL_THREAD_DETACH message will be logged.

When this item is checked, Dependency Walker will inject a small DLL into the application being profiled to help gather details that can only be gathered from within the application itself. When the process being profiled is hooked, Dependency Walker is able to track which modules dynamically load other modules at runtime, as well as what functions are dynamically being called into those dynamically loaded modules. It can also capture the command line arguments passed to child processes. When a process is not hooked, Dependency Walker can still track all dynamically loaded modules, but cannot provide information about which module loaded the dynamic modules, or what dynamic functions were called. See the Using Application Profiling to Detect Dynamic Dependencies section for more information.

This option is only enabled if the Hook the process to gather more detailed dependency information is checked. When checked, all calls to LoadLibrary type functions will be logged to the Log View. When not checked, the calls are still processed, but just not displayed in the Log View.

This option is only enabled if the Hook the process to gather more detailed dependency information is checked. When checked, all calls to GetProcAddress will be logged to the Log View. When not checked, the calls are still processed, but just not displayed in the Log View.

When this option is checked, all thread creations and deletions are logged to the Log View. Also, all other events logged to the Log View, will have the thread I.D. appended to the end. This option can be helpful if you are trying to track down what threads are loading modules and calling functions.

This option is only enabled if the Log thread information is checked. When checked, simple incrementing numbers are used to represent the different threads rather than true thread I.D.'s, which can be lengthy hexadecimal values. This makes following a particular thread's activity easier.

When this option is checked, all first chance exceptions will be logged to the Log View. First chance exceptions should be harmless if handled correctly by the application. Usually, you can leave this option checked, but if you are profiling an application that makes extensive use of first chance exceptions, then you may wish to uncheck this option to reduce unwanted output. If an application does not handle a first chance exception, then a second chance exception occurs and the application is terminated. Dependency Walker always logs second chance exceptions, regardless of how this option is set.

When this option is set, all debug output from the process will be logged to the Log View.

This option lets you control how file names are logged to the Log View. Several of the events that are logged will need to display file names. When this option is checked, full paths to the files will be logged. When this option is not checked, only the file names will be displayed.

When this option is set, each line of log will begin with a time stamp. Each time stamp shows the number of hours, minutes, seconds, and milliseconds that have elapsed since the process started. It is important to note that Dependency Walker can significantly impact the performance of certain operations within the application being profiled. For this reason, these time stamps should probably not be used as an accurate method of measuring the performance of your application.

When this option is checked, Dependency Walker will automatically open and process any child processes of a process being profiled. For example, if you are profiling application A and it decides to launch application B, then Dependency Walker will open a new Module Session Window for application B and immediately begin to profile it using the same profiling settings as application A.