These settings will help you portablize an application and optimize an already portablized application.
The [Redirection] section
Setting | Description |
---|---|
Discovery |
Set to 0 to specify that the JauntePE runtime runs normally, without logging any registry and file system usage information. Set to 1 to specify that the JauntePE runtime run in the "normal" discovery mode that is equivalent to launching the app using the JauntePE launchpad's "Discover Registry Usage" option. Set to 2 to specify that the JauntePE runtime run in a "mixed mode" that allows the app to be run with its normal registry and file system redirection settings and have its overall registry and file system usage captured and output to the discovery log file. Defaults to the application's JauntePE launcher's setting. |
DiscoveryPath |
Some full path, or current configuration ini relative path, which specifies where the "discovery" information is to be written to. Any of the launched application related substitution tokens (%appdrive%, %appdir%, %appname%) may be used anywhere within this path. And environment variable names enclosed within percent signs may be used as well, such as %ComputerName% or %UserName%. You are responsible for ensuring that the environment variable is available on all versions of Windows on which the launch ini will be used. And %pid% may be used as a substitution token for the running application's unique process identifier, %date% may be used as a substitution token for the running application's start date, and %time% may be used as a substitution token for the running application's start time. Defaults to a file named "%appname%_discovery.log" which will be located in the same directory as the application's executable. |
Discovery log file contents
The discovery log file's contents is broken down into two main parts, summary and detail.
Summary log contents
The discovery log file's summary portion is made up of a number of sections containing aggregated information. This information is useful for quick analysis of the application's runtime behavior with regards to concerns of portability.
The following table presents a list of the summary sections along with a description of each section's contents.
Section | Description |
---|---|
RegKey |
This section contains 3 entries: HKEY_CLASSES_ROOT, HKEY_CURRENT_USER, and HKEY_CURRENT_CONFIG. Each one identifies the OS object name used for the given generic registry key name during the discovery run. |
SpecialFoldersLong |
This section contains a list of special folder number/file system path pairings for all of the special folders that were active during the discovery run. The list is sorted by descending file system path. The paths are long paths. |
SpecialFoldersShort |
This section contains a list of special folder number/file system path pairings for all of the special folders that were active during the discovery run. The list is sorted by descending file system path. The paths are short paths. |
RegFuncs |
This section contains a list of the registry related hooked api functions that were used during the discovery run. |
WFSFuncs |
This section contains a list of the file system related hooked api functions that were used during the discovery run. |
PrcFuncs |
This section contains a list of the process related hooked api functions that were used during the discovery run. |
RegModules |
This section contains a list of file names for the execution modules that made calls to one or more of the registry related hooked api functions during the discovery run. The "*" entry is the application's main load module, typically a .exe or .scr. |
WFSModules |
This section contains a list of file names for the execution modules that made calls to one or more of the file system related hooked api functions during the discovery run. The "*" entry is the application's main load module, typically a .exe or .scr. |
PrcModules |
This section contains a list of file names for the execution modules that made calls to one or more of the process related hooked api functions during the discovery run. The "*" entry is the application's main load module, typically a .exe or .scr. |
RegRedirs |
This section contains a list of registry keys that were redirected into the portable registry during the discovery run. |
WFSRedirs |
This section contains a list of file system paths that were redirected into the portable file system during the discovery run. |
PrcRedirs |
This section contains a list of file system paths for launched child applications that the JauntePE runtime was applied to during the discovery run. |
RegWarns |
This section contains a list of "api call detail" section numbers for registry related hooked api function calls that were not redirected during the discovery run. These might need to be redirected in the future since the call either created, modified, or deleted a key or value in the system registry. |
WFSWarns |
This section contains a list of "api call detail" section numbers for file system related hooked api function calls that were not redirected during the discovery run. These might need to be redirected in the future since the call either created, modified, or deleted a directory or file in the file system. |
PrcWarns |
This section contains a list of "api call detail" section numbers for process related hooked api function calls that were not redirected during the discovery run. These might need to be redirected in the future since the call was for a non-portable path. |
RegCreate |
? |
WFSCreate |
? |
PrcCreate |
? |
RegOpen |
? |
WFSOpen |
? |
PrcOpen |
? |
RegModify |
? |
WFSModify |
? |
PrcModify |
? |
RegDelete |
? |
WFSDelete |
? |
PrcDelete |
? |
RegPaths |
? |
WFSPaths |
? |
PrcPaths |
? |
Detail log contents
The discovery log file's detail portion is made up of a numbered section for each call made to one of the hooked api functions. This information is useful when it is necessary to determine the exact nature of the call made with regards to concerns of portability.
The following table presents a list of the values that may be present in each numbered detail section, along with a description of that value's contents.
Name | Description |
---|---|
seq# |
This is the 0-based index in the ascending sequence of calls made to the hooked api functions. Sorting on this value will give the calls in time sequence. |
path |
For hooked registry related api functions, this is the registry key that the call was made for. For hooked file system or process related api functions, this is the file system path that the call was made for. |
full |
Only for calls to hooked file system related api functions, this is the full path equivalent of the call's passed path (in case the passed path was just a file name.) |
func |
This is the name of the hooked api function that the call was made to. |
call |
This is the file name of one of the running application's execution modules that made the call. |
type |
This is the type of the hooked api function that the call was made to: 0=registry, 1=file system, 2=process. |
action |
This is the type of action performed by the hooked api function that the call was made to: 0=create, 1=access, 2=modify, 3=delete. |
redir |
This is an indicator as to whether the call was redirected: 0=not redirected, 1=redirected. |
valtyp |
Only for calls to hooked registry related api functions that manipulate registry values, this is the data type of the value: 0=none, 1=sz, 2=expand sz, 3=binary, 4=dword, 5=big endian dword, 6=symbolic link, 7=multi sz, 8=resource list, 9=full resource descriptor, 10=resource requirements list, 11=qword. |
valnam |
Only for calls to hooked registry related api functions that manipulate registry values, this is the name of the value. @ represents the key's default, or unnamed value. |
valbef |
Only for calls to hooked registry related api functions that manipulate registry values, this is the value of the value before the call was processed. The value is given as a sequence of comma separated hex notation byte values. |
valaft |
Only for calls to hooked registry related api functions that manipulate registry values, this is the value of the value after the call was processed. The value is given as a sequence of comma separated hex notation byte values. |