Microsoft added the ability to manage storage using Storage Management Initiative (SMI-S) providers to Windows Server 2012. Sometimes things don't go quite the way you plan and some debugging is needed to figure out what is going on.
So in order to provide better ability for storage vendors and customers to debug problems encountered with SMI-S providers, the Windows Standards-Based Storage Management Service (I’ll refer to it as Storage Service) offers a tracing facility as well as various other logging options.
CIMXML Logging
If you followed my earlier blogs, you would have learned that SMI-S is an implementation of the Common Information Model (CIM) encoded in XML format (CIM-XML) and transported using the Hypertext Transport Protocol (HTTP).
It is possible to save the requests and responses in a log file so storage vendors can see what requests are issued and what responses were captured by the Storage Service. Most SMI-S providers have similar capabilities and the logs on either side can be compared if problems are encountered.
Normally, this form of logging is not enabled but it can be turned on fairly easily when necessary. It will have some (small) impact on performance, and the log file can get quite large. Note that no security information is recorded in this log so user names and passwords are never captured.
There are a few registry values that control CIMXML logging, all under the key:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Storage Management\CIMXMLLog
Value | Description | Default |
LogLevel | Set this to 4 to enable logging; 0 to disable | 0 (disabled) |
LogFileName | Name of the log file, including the complete path. The NETWORK SERVICE account must have write permission to the directory and file. | %systemroot%\temp\cimxmllog.txt |
MaxLogFileSize | Maximum size of the log file in bytes. When the log exceeds this size, it will be renamed with a .BAK extension and a new file will be opened. At most two files can be saved. | 0x4000000 |
TIP: Although the default file name ends in .txt, I usually change the name to have a .xml extension. When the file is opened in a text editor like Notepad++, the editor applies color coding and allows collapsing and expanding sections of the log, as if it was XML (it’s pretty close, just the timestamps aren't).
The easiest way to enable CIMXML logging is using PowerShell. Open an administrative PowerShell window and use these cmdlets (no line break in the Set-ItemProperty cmdlet):
Set-ItemProperty -Path "HKLM:SOFTWARE\Microsoft\Windows\CurrentVersion\Storage Management\CIMXMLLog" -Name "LogLevel" -Value "4" -Force
Set-ItemProperty -Path "HKLM:SOFTWARE\Microsoft\Windows\CurrentVersion\Storage Management\CIMXMLLog" -Name "LogFileName" -Value "C:\Temp\cimxml.xml" -Force
You may need to restart the service for the change to take effect.
Restart-Service MsStrgSvc
After restarting the storage service, you will have to do a rediscovery operation (Update-StorageProviderCache) to the appropriate level. To disable:
Set-ItemProperty -Path "HKLM:SOFTWARE\Microsoft\Windows\CurrentVersion\Storage Management\CIMXMLLog" -Name "LogLevel" -Value "0" -Force
Restart-Service MsStrgSvc
Note: Logging is only available for SMI-S providers communicating through CIMXML, which is the most common transport. The Storage Service can also communicate with providers implemented under the Windows Management Instrumentation (WMI) framework. This logging function is not available for SMI-S WMI providers.
Windows Event Log
All provisioning activities are recorded in the StorageManagementService Event Log channel (which is enabled by default). Errors are also recorded here. The following sample shows a typical activity that was recorded when I registered a provider using HTTPS. You can see that the user name is logged so auditing of actions carried out through the Storage Service is possible.
Tracing
The Storage Service uses Event Tracing for Windows (ETW) which allows narrowing down issues without using a debugger or source code. In many code paths, the tracing capability has the ability to record unexpected error and warning conditions or informational messages in an Event Tracing Log (.etl) file. Tracing to a file can be enabled by using the logman command line.
Real-time tracing is possible using the TraceView utility (part of the Windows Driver Kit) and the appropriate symbol files. I mention this here so you can see that we have built in a lot of diagnostic capabilities into the service. Typically this information is only valuable to developers. However the public symbols do not contain the tracing information, so this is mostly useful if you need to open a support case.
To enable tracing, use the following command (from a command prompt, not PowerShell):
logman create trace "ETWTrace" -ow -o c:\ETWTrace.etl -p {18C2F19C-F79D-408F-837B-F0B23F20A0F7} 0x3f 0x5 -nb 16 16 -bs 1024 -mode Circular -f bincirc -max 4096 -ets
To stop tracing
logman stop "ETWTrace" –ets