Windows: Debug parameters

These parameters affect the behavior of S-TAP debugging.

These are advanced parameters and are usually modified by IBM Technical Support only.
These parameters are stored in the [DEBUG_OPTIONS] section of the S-TAP properties file:
guard_tap.ini Default value Description
DEBUG_BUFFER 1 1=log the contents of local packets
DEBUG_FIREWALL 1 1=log firewall events
These parameters are stored in the [TAP] section of the S-TAP properties file:
Table 1. More S-TAP configuration parameters for debugging
guard_tap.ini Default value Description
DEBUGLEVEL 0 Level of debug messages to store. Leave at 0 unless directed by IBM Technical Support.
Only critical error information
From v10.1.4: Two "startup" debug logs saved in bin\..\logs. Filename syntax: and startup_hostname_timestamp.old. Files from bin\..\logs get uploaded automatically if upload_feature is on.
All previous messages plus repeatable critical error information
From v10.1.4: Two "normal" debug logs saved in bin\StapBuffer. Filename syntax: and stap_hostname_timestamp.old. Files from bin\StapBuffer are not uploaded.
Not used
All messages from level 1, plus brief information about packets sent to a Guardium system
All messages from level 3, plus local sniffing log
All messages from level 4, plus network sniffing log
All messages from level 5, plus heartbeat receiving log
All messages from level 6, plus miscellaneous debugging information
DUMP_FILE_MODE 0 Enables capture of dump files if S-TAP crashes. When the parameter is not zero, a new dump file is opened every time the S-TAP starts; it is empty if there is no crash.
  • 0: no crash dumps generated
  • 1: crash dumps generated, written to the file stap.diag which is created in the S-TAP working directory. S-TAP copies any existing stap.diag file to a backup file before overwriting the stap.diag file.
  • 2: time-stamped crash dumps generated, written to a file stap-TIMESTAMP.diag which is created in the S-TAP working directory, where TIMESTAMP identifies when the crash dump was generated. If you have issues with crashes, use this option to capture all dumps, not just the most recent one. The timestamp will also help with debugging. This option uses more diskspace, however.
DEBUG_FILE_MODE <install folder>/StapBuffer/stap.txt Deprecated in V10.1.4. Location of the S-TAP debug file. Default until 10.1.4 is <install folder>/StapBuffer/stap.txt.

v10.1.4 and higher: If the debuglevel > 0, then the log from the previous S-TAP session (if it exists) is saved as: %STAP_DIR%\Bin\StapBuffer\stap_%HOSTNAME%%YY-MM-DD%%HHMMDD%.old and the new log is created as: %STAP_DIR%\Bin\StapBuffer\ In addition to this, start-up logs containing just messages related to S-TAP start-up are always generated in %STAP_DIR%\Logs: startup_%HOSTNAME%%YY-MM-DD%%HHMMDD%.old and

STACK_TRACE_FILE_MODE   Deprecated in V10.1.3. Similar to dump_file_mode
SYSLOG_MESSAGES 1 1= send messages to EventViewer. 0=do not send messages.

If the parameter is not set, the following value is used. If the STAP installation folder is rooted anywhere but C:\Program Files (x86)\... then the WER dump folder is set to the full path ending in ...\Windows S-TAP\Bin\..\Logs. If the STAP installation folder contains the text "(x86)" in it, the dump folder is set to C:\Guardium\Dumps and that path will be created by the STAP process.

For example, if Windows S-TAP is installed to C:\PROGRAM FILES\IBM\WINDOWS S-TAP and uses default values for WER_DUMP_FOLDER, WER_DUMP_COUNT, Windows S-TAP uses the following registry settings, then Windows S-TAP crash dump is generated via Windows Error Reporting (WER) facility when it's crashed.

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\Windows Error Reporting\LocalDumps\guardium_stapr.exe

DumpCount REG_DWORD 0x1


DumpType REG_DWORD 0x2


Max value is 5.