OpDesk offers several troubleshooting tools to help quickly resolve issue.
Non Driver Logging
The following binaries create and append log data to the C:\ProgramData\OpDesk\Logs folder.
CustomAgentInstallActions.log – Only used during the installation of the agent.
RasmAgentService.log – All the agent service logging and its plugins will get logged to this file.
RasmLauncher.log – The RasmLauncher is used to impersonate the correct user and environment to properly launch an application.
RasmNetworkService.log – This light weight service is used to gain access to network resources while the user is not logged into the system.
RasmUser.log – Each logged in user will have its own copy of RasmUser running but all log to the same log file. RasmUser is used to diplay UI to the end user and to start the RasmLauncher with the proper permissions.
Most of the logs automatically roll any previous logs to the same name with a number attached. For example, RasmAgentService-0.log will be the most recent RasmAgentService log before the current log. Each higher number represents the next older log. Any old logs that are more than 15 days will be automatically deleted when the binary restarts.
As with most filter drivers, we discourage turning on kernel mode logging in a verbose mode because it can adversely affect general OS performance. However there are times verbose driver logging can be very helpful to track down an issue. This log currently doesn’t get removed or rotated, we turn it off by default. You can configure driver logging by changing the following values in the HKLM\Software\OpDesk\OpDeskAgent registry key:
1. DriverLogCategoryLevel – This setting tells the driver what types of data to log based on its category. This is a flag setting so you can combine several categories into a single number. For example, the default settings are RASM_LOG_CATEGORY_DRIVER_ENTRY, RASM_LOG_CATEGORY_VIRTUAL_PROFILE and RASM_LOG_CATEGORY_APP_INSTALL. So we can take their hex values and OR them together using a programming calculator ( 0x000010 + 0x000100 + 0x000020 = 0x000130 ) or 304 in Decimal.
Here are the current categories that can be turned on. You can turn them all on of by setting the value to be 0xFFFFFF.
RASM_LOG_CATEGORY_NONE = 0x000000,
RASM_LOG_CATEGORY_CAPTURE_APP_DATA = 0x000001, //Log info about file/registry creations, renames deletions we capture from the app after its installed so we know what to remove during reinstall/reset
RASM_LOG_CATEGORY_CAPTURE_INSTALLER_DATA = 0x000002, //Log info about what the installer doing so we can make a package
RASM_LOG_CATEGORY_MEMORY = 0x000004,
RASM_LOG_CATEGORY_HASH = 0x000008,
RASM_LOG_CATEGORY_DRIVER_ENTRY = 0x000010,
RASM_LOG_CATEGORY_APP_INSTALL = 0x000020,
RASM_LOG_CATEGORY_VARIABLIZE = 0x00040,
RASM_LOG_CATEGORY_ESB = 0x000080, //Enterprise Service Bus messages
RASM_LOG_CATEGORY_VIRTUAL_PROFILE = 0x000100,
RASM_LOG_CATEGORY_LAZYY_INSTALLER_THREAD = 0x000200,
RASM_LOG_CATEGORY_SERVICE_COMMUNICATION = 0x000400, //Driver to Service and vice versa
RASM_LOG_CATEGORY_ISOLATION = 0x000800,
RASM_LOG_CATEGORY_ALL = 0xFFFFFF
2. DriverLogSeverityLevel – The following logging severity levels are available:
Error + Info: 1
Error + Info + Warning: 2
Error + Info + Warning + Trace: 3
The default setting is 2 or (Error + Info + Warning).
3. DriverLogToFile – This tells the driver to output to a Rasm.sys.log file in the C:\ProgramData\OpDesk\Logs folder. Set it to be 0 to turn off file logging or 1 to turn it on. Please note logging statements will still be sent to the kernel debug screen even if this setting is turned off. To improve performance the driver opens the log once when it starts and only closes it when the driver is unloading. This can cause the log size to be reported incorrectly and possibly the last log statements to be truncated if the system is suddenly powered off and the driver hasn’t had a chance to purge its buffer. You can unload the driver using “fltmc unload rasm” to ensure the log gets completely written out.
Both Driver and non driver logging use the same formatting to make it easy to match up time stamps to help track down issues. For example when an application is launched, the following binaries are involved: RasmUser, RasmLauncher, RasmAgentService and Rasm.sys. The logs for each would need to be observed to get a complete picture of the entire application launch process.