Share via


Modular Stress Test Command-Line Options

The Modular Stress Test executes the oemstress -ini:\oemstress.ini -autooom -wait commands on default execution from the CETK. You can modify the behavior of the test by editing the command line. For information about modifying the command line, see Editing the Command Line for a Test.

The Modular Stress Test can run in either normal mode or command mode. If there is an instance of the Modular Stress Test that is already running, subsequent instances of the Modular Stress Test run in command mode. Certain command-line options have an effect only in command mode.

Do not insert white space between a command-line option and its corresponding value. Enclose paths that include spaces with double quotation marks.

The following table shows the command-line options for the Modular Stress Test.

Command Result
-result[:[cesh:]result_file_path]
If you run the Modular Stress Test from the CETK, specifying this option has no effect. If you specify -result only, test results are logged to the default Result.xml file at the default location in the release directory on the development workstation.

If you use the cesh: prefix, a results file is created on the development workstation in the release directory. If you specify a file name with an .xml file name extension, the harness creates the results file in Extensible Markup Language (XML) format. If you specify any other file name extension, the harness creates the results file in text format. It is recommended that you create the results file on a non-volatile storage medium to avoid data loss if the target device crashes.

Generation of a results file is not enabled by default.

-history[:[cesh:]history_file_path]
If you specify -history only, test results are logged to the default History.csv file at the default location in the release directory on the development workstation.

If you use the cesh: prefix, a history file is created on the development workstation in the release directory. It is recommended that you do not create a history file on the target device, because the history file can become large.

Generation of a history file is not enabled by default.

-ini:[cesh:]initialization_file_path
Specifies the file name and location of an initialization file. If you use the cesh: prefix, the initialization file is on the development workstation in the release directory.

Even if you do not specify this command-line option, usage of an Oemstress.ini initialization file in the release directory is enabled by default. The harness expects the initialization file to be in the release directory.

-ht:hang_trigger_time
Specifies a length of time, in minutes, after which the harness considers some or all of the test modules to be hung. The default length of time is 30 minutes. If you specify 0 for hang_trigger_time, hang detection is disabled.

If you attach a debugger to the target device, the debugger breaks into code when the harness detects that a module is hung. If a debugger is not attached to the target device, the harness records which modules are hung in the results file and in the Output window in the Platform Builder IDE.

-ho:[any|all]
If you specify -ho:any, when any test module runs for longer than the length of time specified by the -ht command-line option, the harness considers the module to be hung.

If you specify -ho:all, when all test modules run for longer than the length of time specified by the -ht command-line option, the harness considers the modules to be hung.

-rt:requested_run_time
Specifies the total time, in minutes, after which the harness should terminate testing. The default length of time is 900 minutes. If you specify 0 for requested_run_time, the harness runs tests for an indefinite length of time.
-ri:result_refresh_interval
Specifies the time interval, in minutes, at which the harness refreshes the results file and the Output window. The default value for the time interval is 5 minutes. Status information is also appended to the history file.
-md:module_duration
Specifies the length of time, in minutes, for which each module is requested to run when launched by the harness. The default value is 10 minutes.

If you specify random for module_duration, the harness runs the module for a random length of time, up to the maximum length of time specified by the -ht command-line option. Module runtime can be infinite if hang detection is disabled.

If you specify indefinite for module_duration, the harness runs the module indefinitely, up to the maximum length of time specified by the -rt command-line option. Specifying indefinite disables hang detection.

If you specify minimum for module_duration, the harness runs each module for only its minimum runtime.

-mc:module_count
Specifies the maximum number of test modules that the harness can run at any given moment. The default value is 4.
-seed:random_seed
Specifies a random seed to use. By default, the harness uses the value returned by the current tick count.
-vl[:[abort|fail|warning1|warning2|comment|verbose]]
Available in both normal and command modes. Specifies a verbosity level for the logs from the test modules. If you specify -vl only, the harness enables full verbosity. By default, the harness enables abort, failure, warning1, warning2 and comment verbosity levels.
-server:server_name
Specifies a server name to be passed on to the test modules. By default, server_name is set to localhost.
-terminate
Available in command mode only. Sends a termination request to an already running instance of the harness.
-wait
Specifies that the harness wait for completion of the currently running test modules after running for the total requested time specified by the -rt option. This option has no effect if the value specified in the -md option is random or indefinite.
-autooom
Enables a feature that can automatically close an application on the target device at random or reduce the amount of memory allocated to the object store to increase the amount of available application memory.
-trackmem:[high_watermark%|low_watermark[B|KB|MB]]
This option is useful only when you attach a debugger to the target device. If you specify high_watermark%, the Modular Stress Test breaks into the debugger if total memory usage on the target device exceeds the percentage specified by the value of high_watermark.

If you specify a value for low_watermark with a trailing B, K, KB, M, or MB, the Modular Stress Test breaks into the debugger if the available physical memory is less than the value of low_watermark. If you do not specify a unit of measurement, the Modular Stress Test assumes that you are specifying a number of bytes.

See Also

Modular Stress Test | Running the Modular Stress Test | Running the Modular Stress Test from the Command Line

 Last updated on Friday, October 08, 2004

© 1992-2003 Microsoft Corporation. All rights reserved.