Ask the Performance Team

Great blog post on RDS in Windows Server 2012

Blake Morrison - MSFT — Fri, 11 May 2012 13:08:00 GMT

Good morning Folks! Today is a quick post to inform you of a new Blog from the Windows Server team that talks about the new RDS (Remote Desktop Services) features in Windows Server 2012. Check it out!

Windows Server 2012 Remote Desktop Services (RDS)

Have a great weekend!

Improve caching for CSR

Blake Morrison - MSFT — Fri, 27 Apr 2012 11:00:00 GMT

In previous versions of Windows, clients with remote connections would often initiate network traffic to retrieve remote information from a print server, resulting in a resource-consuming call to the server. This behavior was more significant when Client Side Rendering (CSR) was used that caused increased communication with the remote server. Many applications use certain APIs to query the print spooler for print information at startup, at document creation time, and when displaying available fonts. This often resulted in visible delays or hangs in the applications from the user’s perspective. In Windows 7 and Windows Server 2008 R2, the performance of many spooler API calls has been improved through more aggressive caching that will reduce the remote server calls and improve end user performance.

In general, the intent of the enhancements has been to decouple applications that use client print APIs (winspool.drv) from the print server to avoid application UI delays. Some of the APIs that are used by major client applications such as the print dialog and Microsoft Office have had their caching behavior improved. OpenPrinter, EnumJobs, and some forms of GetPrinterDriver are the main APIs that will see caching improvements.

Overview of CSR caching behavior

The CSR provider maintains a cache of print connection data for remote connections. This cache is persisted in the registry and loaded at provider startup. The cache follows a “pull” model and in general operates asynchronously. Calls requesting remote connection data are serviced from the local cache immediately where possible, and an asynchronous work item is queued that will synchronize with the remote server if necessary. Only in the case where the remote data is not cached locally will the call go over the network synchronously. The asynchronous synchronization with the remote server is done only periodically; most cache entries have an expiry time of 120 seconds. Cache coherency is enforced by checking Change IDs associated with both the local cache and the remote connection. If a request is made for cached data last accessed over 120 seconds ago, the remote Change ID will be compared to the local one, incurring a single RPC call of overhead. If they differ the cache will be updated from the remote server, incurring one or more RPC calls.

Caching behavior of common APIs

The table below shows the caching characteristics of common print APIs. The cache refresh interval for each caching mode is described in the next section.

Caching behavior of key print APIs

API	Caching Behavior	Caching Mode	Changed from previous versions ?
OpenPrinter	Cached. Client spooler still initiates network traffic for “Set” API calls and opens the remote printer handle when absolutely necessary. OpenPrinter learns the server response per access mask; this it may block while populating the cache with results for masks it hasn't seen before.	Normal	Yes
EnumJobs	Cached. Certain operations, like creating a job, cause an update of the EnumJobs cache.	Volatile	Yes
GetPrinterDriver	Cached when there is a printer connection to the target server.	Normal	Yes, but only for level 8 calls
EnumForms	Cached for both server and printer handles when there is at least one printer connection to the target server. Not cached otherwise.	Normal	No
EnumPrinterDrivers	Not cached.	Normal	No
EnumPrintProcessorDatatypes	Cached.	Normal	Yes
GetPrinter	Cached when there is a printer connection to the target server. Not cached otherwise.	Normal	No
GetJob	Not cached.	Normal	No
EnumPrinters	Cached for Level 4. Level 4 only returns data when there are print connections.	Normal	Yes
EnumPorts	Not cached.	Normal	No
OpenPrinter2	Cached based on flag. Calls with ‘NO_CACHE’ flag will not be cached. Calls without the ‘NO_CACHED’ flag will be cached.	Normal	No

Registry keys for cache refresh intervals

Two registry key values control the cache refresh behavior for print APIs. Caching mode “Normal” is controlled by the following registry key value and defaults to 120 seconds:

HKLM\Software\Policies\Microsoft\Windows NT\Printers\SyncCacheAgeUser

Caching mode “Volatile” is controlled by the following registry key value and defaults to 0 seconds:

HKLM\Software\Policies\Microsoft\Windows NT\Printers\SyncCacheAgeVolatile

-Bernd Hogen

Task Scheduler Error “A specified logon session does not exist”

Blake Morrison - MSFT — Wed, 18 Apr 2012 11:00:00 GMT

Good morning AskPerf! Kapil Patry here from the Microsoft Platforms Support Team. I am blogging today about an issue I recently worked. This particular issue dealt with the creation of a task using Task Scheduler on a Windows 2008 R2 Server (can occur on Windows 7 as well). When I attempted to create a scheduled task, the following error appeared:

Task Scheduler

An error has occurred for the task <task name>. Error message: The following error was reported: A specified logon session does not exist. It may have already been terminated..

This error came up whether I was logged on as a Local Administrator, Domain Administrator, or any other user that had rights to log on locally.

After extensive research, I found that the above error will only occur if the following Security Policy is enabled and you select the “Run whether user is logged on or not” Security option on the General tab, when creating a new task:

Network access: Do not allow storage of passwords and credentials for network authentication

To resolve this issue, simply Set this policy to Disabled:

The new version of Task Scheduler (Windows Vista onwards) uses Windows Credential Manager to store the credentials of the account that is specified to perform a task. If the Network access: Do not allow storage of passwords and credentials for network authentication policy is enabled and applied, Credential Manager cannot store the credentials locally, thus this error message appears.

NOTE you will not receive this error if the “Run only when user is logged on” Security option on the General tab is selected (we do not store passwords in this scenario).

Addition Resources

-Kapil Patry

Migrating Print Queues quickly using PRINTBRM, configuration files, and the Generic/Text Only Driver

Blake Morrison - MSFT — Tue, 03 Apr 2012 11:00:00 GMT

Good morning AskPerf! Digvijay here to chat about print server migration. All server admins have probably had an opportunity to migrate print servers. This process can be fast and easy when migrating between the same versions of operating systems; and can be done with a bit of effort moving between Operating Systems with different architecture (e.g., moving from 32-bit to 64-bit versions of Server 2008). However, things really get challenging when we have to migrate from an older Operating System to the latest Operating System on a different architecture. (e.g., from Windows 2003 Server x86 to Windows Server 2008 R2 x64). Fortunately, there are new tools such as the Print Management Console that ships with Server 2008 R2 or, if you prefer the command line interface, then you can use PRINTBRM.EXE. However, there can be some hurdles getting all the printers migrated successfully if we do not understand the Printer restoration process and fulfill necessary pre-requisites.

Things to keep in mind during printer migrations:

1. A print queue cannot function without a driver of the same server architecture (x86 or x64) on which it exists.

2. Unless the print processor is migrated successfully, the print queue will not show up.

3. If you are migrating from a 32-bit Operating System to a 64-bit Operating System, it is important that you have 64-bit drivers pre-installed for all of your printers, along with the 32-bit drivers. (Remember that for a 64-bit client to print to print server hosted on 32-bit Operating System, you need the 64-bit version of the driver.)

4. When a cross-architecture migration includes the migration of printer language monitors, an error will occur during the process of restoring the printers to the destination server using the PRINTBRM command-line tool. The reason for the error is that language monitor driver architecture must always be the same as the source server architecture. Therefore, when migrating from x86-based architecture to x64-based platforms, language monitor migration cannot be successful. An error posted to the event log will state that the source architecture is not the same as that of the destination server. More info about this behavior can be found in the Print Services Migration Guide.

5. When using PRINTBRM, always run commands from an Administrative command prompt

If performing a 32-bit to 64-bit migration and all the existing client machines are 32-bit, then you will have to install 64-bit drivers for all the 32-bit drivers before starting the migration. It is common to have third-party 32-bit printer drivers that do not have 64-bit equivalents. For those instances, we typically suggest using universal drivers if available but contacting the printer vendor for their input is the safest bet.

During the Printer restore in cross-platform scenarios, if the backup file does not contain driver binaries for target server platform, PRINTBRM will attempt to install the drivers from the target server’s driver store if a matching driver is available. If a matching driver for the target platform is not available (either in the backup or on the server) then the print queue will not be created and there will be errors. See below:

We will see relevant events in the event viewer also:

So to make it easy for everyone to understand, here is the straightforward way to successfully restore all the printers:

1. Install 64-bit drivers on the Windows 2003 x86 Print server (source) or install all the required 64-bit drivers on the 2008/R2 Server (target). Keep in mind that the driver name string must be an exact match. If the names do not match exactly, the migration will treat it as if the driver is not present.

2. Take a backup of the printers on the Windows 2003 source server using the Print Management Console or printbrm.exe run from the Windows 2008 R2 Server.

3. Import the backup to the 2008 R2 server.

NOTE We need to preinstall any driver that has different components when installed on x86 than when installed on x64. As long as the driver is installed then the printer installation will not be blocked unless there is a non-existent Monitor value in the Printer registry key. If the printer (not the driver) requires this setting, then we will need to install the driver that uses this monitor on the x64 machine. If there is no x64 monitor provided by the vendor or if the vendor provides a new x64 monitor that uses a different name, then you will need to add a printer using the x64 version of the driver on the new machine since the vendor providing the driver did not provide compatibility to the new OS.

Keeping it simple

To avoid most of these driver and component pitfalls, it’s often easiest to switch all the print processors and print monitors on the source server over to some basic defaults ones (eg: cleaning up the PRINT registry before starting with the migration). This will speed up the process and maximize the number of queues successfully migrated.

Microsoft has provided a Spooler FixIT for Windows 2003/2008 to automate the spooler cleanup process. See our previous AskPerf blog entry for information about the functionality and usage of this tool.

We also recommend removing old and unused drivers from the server before taking a backup.

However, if you do not want to go through this lengthy process of fulfilling these prerequisites, are on a time crunch, want to quickly restore the print queue information on the target server and deal with the driver worries later, then read on.

In order to quickly get the queues migrated to the new server, we can create them using the “Generic / Text only” printer driver without restoring any of original the drivers on the target. Remember that we need to have 64-bit drivers present either in the package or on the target server for the restore to finish and the print queue to be available for printing.

Here are the steps to successfully migrate all of your print queues using the in-box “Generic/Text Only” print driver:

1. On the source Windows 2003 Server, change all print processors to winprint using the following setprinter.exe command:

SetPrinter.exe \\Servername 2 pPrintProcessor="Winprint"

This can also be accomplished using WMI:

wmic printer set PrintProcessor = WinPrint

2. Install the latest update for Printbrm on the target 2008R2 server:

KB 2636591 An update to improve the restore operation performance of Printbrm.exe in Windows 7 or in Windows Server 2008 R2

3. Install a local printer on the target 2008 R2 server using the Generic / Text Only driver and share it to enable the firewall exceptions for the Print Services.

4. From the Windows 2008R2 server, take a backup of the 2003 print server using the nobin switch

(we are using the nobin switch since we don’t want to migrate any of the print drivers):

Printbrm.exe –b –s \\servername –f nobin.printerexport –nobin

5. Next, we have to modify the contents of the backup files. Expand the printerexport backup to a directory and the replace the BrmDrivers.xml, BRMLMons.xml and PProcs.xml files. The command to extract the files to a directory is:

printbrm.exe -r -d c:\temp\expand -f nobin.printerexport

The Expanded directory will look similar to this:

BrmDrivers – contains a list of every driver installed on the computer and the driver files for each driver
BrmForms – contains a list of all the installed forms
BrmLMons – will usually contain either Windows NT x86 or Windows x64 as the architecture and a list of port monitors and the port monitor files installed
BrmPorts – contains a list of all the installed printer ports
BrmPrinters – contains a list of all printers that have been installed
BrmSpoolerAttrib – contains information about the spooler directory path and also indicates whether or not the source server was a cluster server

6. Now we need to edit the existing xml files and delete the information about unused print processors, language monitors and drivers in them and then create a new file without these components.

NOTE You may ask if we already set all the printers to use WinPrint as default print processor using the earlier methods, then why do I need to do this? The answer is that when we take a backup using PRINTBRM, the tool copies all the files from their respective directories inside C:\Windows\System32\spool\. Hence even if we have replaced the information on the queues, these files will be backed up and at the restore operation, they will also be restored. So even though we took a backup using the nobin switch, the xml files contains information about all the drivers. When you attempt to restore, the server will try to look for these drivers and restore them. Also, the -nobin switch only omits the driver files, the Language monitor and the Print processors are still backed-up.

For creating new BrmDrivers.xml, BRMLMons.xml and PProcs.xml files, we can use the following templates:

BrmDrivers.xml

===========

===========

BRMLMons.xml

==========

==========

PProcs.xml

========

</PPROCS>

=========

7. Once we have saved the new xml files in place, we will re-pack the backup using this command to get a new backup file that we will use to restore on the target server:

printbrm.exe -b -d c:\temp\expand -f newbackupfile.printerexport

8. Now that we have a clean printer backup, we will use the BRMConfig file to create all the printers using the “Generic / Text only” driver. The BRMConfig.xml file needs to have a mapping of all the drivers present on the source server that we want to restore with the Generic / Text Only driver.

A sample BRMConfig file may look like this:

=============

</PLUGINS>

</DriverMap>

</BrmConfig>

==================

For restoring all the printers from the backup, we need to mention all the existing drivers here.

NOTE The name of the driver has to be an exact match.

9. Once you have your brmconfig.xml file finished, run this command to start the restore:

printbrm –r –s \\2008R2Servername –f newbackupfile.printerexport -c c:\temp\brmconfig.xml

NOTE We need to provide the absolute path of the BrmConfig.xml file here.

10. If all the mentioned instructions have been followed, you will see all the print queues getting created on the server using the Generic / Text Only driver.

This is where we started from:

And this is what we have accomplished:

11. Verify that the printers are working fine by sending some test pages to the printers.

12. After the queues are created on the target server, you can install the 64bit drivers for the printers as per your convenience and then switch the queues again.

Simplifying the BRMConfig.xml file creation

Considering most typical production scenarios, Print Servers you have hundreds of print queues and many print drivers, creating the BrmConfig.XML file for mapping each driver to Generic / Text Only driver can be real time consuming process. To ease the pain of creating this file yourself, there’s a BRMC tool that will come in handy. Download the tool from https://brmc.codeplex.com/ and run it from the directory where the BRMDrivers.XML is located. (So run it from the expanded location). Once the tool is run, and it creates a BRMConfig.xml file, pack the backup and then run the restore using the BrmConfig.XML file (to to step 8 and then go to step 10).

The BRMC tool creates the brmconfig.xml file that has the driver mappings. It also creates clean BrmDrivers.xml, BRMLMons.xml and PProcs.xml in the same directory. Be aware, the tool overwrites the original files, so save the original .printerexport file as a backup of BrmDrivers.xml, BRMLMons.xml and PProcs.xml.

Troubleshooting

If you encounter any errors during a Print Migration restore, check the event logs for possible causes. Common ones may be Print Processor is unknown, Unknown Port, or Print driver is unknown which usually means that the spooler was not cleaned properly on the source server when the initial backup was generated. Look for more in-depth troubleshooting of these kinds errors in a future blog.

I hope this information will come in handy the next time you are working through a printer migration. Until next time…

Addition Resources

-Digvijay

Windows Performance Monitor Disk Counters Explained

Blake Morrison - MSFT — Fri, 16 Mar 2012 21:43:58 GMT

Hello AskPerf and Happy Friday! This is just a quick post to let you know that Flavio, one of our Disk Experts on the Core team, has posted another informative blog post; this time on Performance Monitor Disk Counters. Check it out and have a great weekend!

Windows Performance Monitor Disk Counters Explained

http://blogs.technet.com/b/askcore/archive/2012/03/16/windows-performance-monitor-disk-counters-explained.aspx

-Blake Morrison

Print update rollup available for Windows 7 & Windows Server 2008 R2

Blake Morrison - MSFT — Fri, 16 Mar 2012 13:45:06 GMT

A new printing hotfix rollup was released that updates the core print spooler components localspl.dll, splwow64.exe, spoolsv.exe, win32spl.dll, and Winprint.dll. This rollup is designed to reduce known issues such as printing performance, print spooler crashes, connectivity to print queues, and print driver installation.

To download the update and get more information on the fixes included in this rollup, please see KB article 2647753: Description of an update rollup for the printing core components in Windows 7 and in Windows Server 2008 R2

Many of the printing related support cases at Microsoft are resolved by one of the included hotfixes. We highly recommend installing this hotfix rollup when troubleshooting any printing related issues.

Unable to connect to WMI locally – “Win32: The system cannot find the path specified”

Blake Morrison - MSFT — Fri, 09 Mar 2012 12:00:00 GMT

Good morning AskPerf! Sanket Jagtap here from Platforms Team here to discuss an interesting issue I recently worked. My customer had a Windows 2008 R2 Server, and could not connect locally to WMI. When they ran “wmimgmt.msc” and tried to connect, the following error appeared:

Failed to connect to <local computer> because "Win32: The system cannot find the path specified."

When this failed, the following events were recorded to the Application log:

Log Name: Application
Source: Microsoft-Windows-WMI
Date: <Date/Time>
Event ID: 28
Task Category: None
Level: Error
Keywords: Classic
User: N/A
Computer: <Computer Name>
Description: Failed to Initialize WMI Core or Provider SubSystem or Event SubSystem with error number 0x80070003. This could be due to a badly installed version of WMI, WMI repository upgrade failure, insufficient disk space or insufficient memory.

Log Name: Application
Source: Microsoft-Windows-WMI
Date: <Date/Time>
Event ID: 43
Task Category: None
Level: Warning
Keywords: Classic
User: N/A
Computer: <Computer Name>
Description: Windows Management Instrumentation ADAP failed to connect to namespace \\.\root\cimv2 with the following error 0x80070003

We checked the WMI Security tab, and the Root namespace was missing, as well as under the Advanced tab:

During the course of troubleshooting, we tried running “winmgmt /verifyrepository”, however it failed with a similar error:

C:\>winmgmt /verifyrepository
WMI repository verification failed
Error code: 0x80070003
Facility: Win32
Description: The system cannot find the path specified.

At this point, we decided to run the WMIDiag Tool (WMIDiag 2.1) to help troubleshoot this issue. The WMIDiag log reported the same error multiple times for most of the Root namespace:

1843 12:43:16 (0) ** - Root, 0x80070003 - The system cannot find the path specified.
Error Result: 0x80070003 ( -2147024893 )
ID Defined as: ERROR_PATH_NOT_FOUND
Message Text: The system cannot find the path specified.

We then popped open the Registry and browsed to the following key:

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\WBEM\CIMOM]

We compared a working to a non-working registry and made the following discover:

Working Machine

Non-Working Machine

The registry “Type” was set to REG_SZ instead of REG_EXPAND_SZ. We took a backup of the CIMON folder, then deleted the old “Repository Directory” value and created a new one using the REG_EXPAND_SZ type. After a restart, WMI now successfully connected to the Repository/Default Namespace.

Unfortunately, we were unable to determine what changed this value, however it could have been a user change, some type of script, or caused by an application.

Additional Resources

- Sanket Jagtap

Performance issues due to Inactive Terminal Server Ports

Blake Morrison - MSFT — Tue, 06 Mar 2012 12:00:00 GMT

Good morning AskPerf! There are several issues that have been associated with a high number of inactive Terminal Server ports. Delayed logon times to RDP sessions, failure of printers to redirect, and slow server performance due to registry bloat from all the ports. These inactive TS ports accumulate because the Remote Desktop Services Device Redirector service creates a new port every time an RDP session is established, but the ports are not always recycled. Every RDP session can possibly create a new port, and every ended session means a new inactive port. Performance degradation is known to occur when 250 or more TS ports exist in the registry. Increasingly large numbers of redirected devices will exacerbate performance delays.

To eliminate any issues these TS ports may cause, we have a new Windows Server 2008 R2 hotfix. The Hotfix can be downloaded here - KB 2655998 Long logon time when you establish an RD session to a Windows Server 2008 R2-based RD Session Host server if Printer Redirection is enabled. This hotfix will prevent inactive TS ports from accumulating in the future, but you also have to clean up any currently inactive TS ports using the Fixit tool included in KB2655998. The FixIT tool itself can also be downloaded directly from http://go.microsoft.com/?linkid=9799054. The FixIt tool will remove the entries already accumulated under the TS ports registry key below:

[HKLM\SYSTEM\CurrentControlSet\Control\DeviceClasses\{28d78fad-5a12-11d1-ae5b-0000f803a8c2}\##?#Root#RDPBUS#0000#{28d78fad-5a12-11d1-ae5b-0000f803a8c2}]

Because the Hotfix and the FixIt perform two different functions, you must install the Hotfix and run the FixIt one time on your 2008 R2 Remote Desktop Server.

For down-level operating systems such as Server 2003, Server 2008 Terminal Servers and Windows 7 in a VDI scenario, we highly recommend a scheduled task be created to execute the Inactive TS Port FixIt on a bi-weekly basis, since the hotfix only supports Windows Server 2008 R2 at this time.

The FixIt is an MSI package so you can run it silently with no user interaction required. Follow these simple steps:

1. Locate the MSI file in Windows Explorer and note the exact path to it

2. Click Start and type in the following:

msiexec /package “path” /quiet

For example, if the MSI file MicrosoftFixit50833.msi is located in the “temp” folder of your C drive, then the path would be C:\temp\MicrosoftFixit50833.msi and the command would look like this:

msiexec /package “C:\temp\MicrosoftFixit50833.msi” /quiet

3. To add logging and check the results, use this command:

msiexec /package "c:\temp\MicrosoftFixit50833.msi" /quiet /log c:\temp\MSI50833.log

Additional Resources

MSIEXEC commands http://support.microsoft.com/kb/314881
Available Updates for Terminal Services (Remote Desktop Services) in Windows Server 2008 http://support.microsoft.com/kb/2312539
Available Updates for Terminal Services (Remote Desktop Services) in Windows Server 2008 R2 http://support.microsoft.com/kb/2601888

-Jess Cunningham

Internet Printing – How Windows decides if http or RPC is used for a Print Connection to an IPP Server

Blake Morrison - MSFT — Fri, 02 Mar 2012 12:00:00 GMT

We often get asked from time to time how to force printers that a user has installed on their workstation using the IPP website to use RPC in lieu of the Internet printing protocol. There is a document available on TechNet that explains how to accomplish this:

http://technet.microsoft.com/en-us/library/cc757981(WS.10).aspx

(It’s as simple as changing the IE Zone Security to Medium-Low)

Often though, we run into customers who have already customized the settings in their IE Zone security and would still like to force the use of RPC for IPP printers without resetting those IE Zone settings to Medium-Low.

So what settings is the IPP printer really checking to accomplish this?

The process Windows uses to decide how to connect to a printer looks like this:

1. The OS checks if the following Registry Key is set:

[HKEY_CURRENT_USER\Printers\Settings\PreferredConnection]

If this key exists and its value is 0, the printer connection is using HTTP.

2. If the Registry Key is not set we are looking for two Settings:

a. Java Permissions

This Setting cannot be made inside IE. You have to configure the Settings with GPO.

Java Permissions need to be at least set to Medium Safety to use RPC.

b. ActiveX

Additionally the OS checks the Value from “Initialize and script ActiveX controls not marked as safe for scripting”.

If the Value is disabled we will use RPC otherwise we will use HTTP for the Print Connection.

A last pre-requisite is that the Protected Mode in IE needs to be turned off to use RPC

-Bernd Hogen

Windows Server 8 beta now available!

Blake Morrison - MSFT — Thu, 01 Mar 2012 16:14:19 GMT

This morning Bill Laing, Corporate Vice President of Server and Cloud Announced the beta release of Windows Server “8”. I think it is really important for anyone who is interested in hearing more about what is coming in this beta with Hyper-V and our Virtualization development efforts; please go read what Bill has to say.

In the coming days and months, there will be more Windows Server “8” blog posts coming from Bill Laing and his leadership team on the Windows Server Blog.

Also, stay tuned in the coming days and weeks for more deeper dives in the supporting technologies here. I have been waiting to start talking, so hope you have some time carved out to learn more about Windows Server “8” technologies.

Download Windows Server “8” Beta here

-Blake Morrison

Windows 8 Consumer Preview available now!

Blake Morrison - MSFT — Thu, 01 Mar 2012 13:54:13 GMT

Good morning AskPerf! Yesterday we announced the availability of the Windows 8 Consumer Preview (beta) for download/testing. This is huge for our Client OS business and we encourage you to download and play around with it. Please see the following links for information and the download location for the Windows 8 beta.

Windows 8 Consumer Preview

Windows 8 Download Link

Welcome to Windows 8 – The Consumer Preview

Running the Consumer Preview: system recommendations

Windows 8 Consumer Preview Product Guide for Business

We will be Blogging more about the exciting new features from a “Performance” standpoint over the coming months, so stay tuned!

-Blake Morrison

Microsoft Fixit for Printing

Blake Morrison - MSFT — Fri, 24 Feb 2012 12:00:00 GMT

Good morning AskPerf world! Jeff Hagler from the Remote Resources team here to chat about printing. How many of you have ever dealt with an issue where you just knew that something was wrong with your print spooler but could not quite put a finger on it? Maybe print jobs were slow, certain users could print to some printers but not others, or maybe nobody could print at all?

Back in the day, we included a tool with the Windows 2003 Resource Kit called Cleanspl that was able to make sure that the spooler service was configured correctly and clear of any third party dependencies that may be referencing bad/missing files. Cleanspl is a great tool, but by being hidden in the resource kit, it was rarely used. Up until now, this tool did not exist/work in recent Operating Systems like Windows Server 2008..

We are happy to announce the same functionality in Cleanspl (and a bit more) has been built into one of our Fixits that will run on Windows XP/2003 and Windows Vista/2008 and can be downloaded from here. If you are running Windows 7 or Server 2008 R2, have no fear as we have a similar tool for you in the works right now, and we’ll update this blog with a link as soon as it becomes available.

This Fixit package consists of two modes: Light and Full. Light will make changes to the spooler that should not require your end user to make any changes, while the Full mode will restore the print spooler to defaults and will require a complete reinstall of your print drivers and printers. Think of the Light version as something you can run on any system (print server, terminal server, normal client system) as a first troubleshooting step, and the Full version as something to reserve for systems that get their printers and print drivers pushed down from Print Servers (via Group Policy and Point and Print). Let’s cover the key part of the previous statement again – do not run the Full version on a Print Server as it will delete all the printers. Basically, it puts your Print Environment back to the way it was when the OS was installed.

When you first run the Fixit on your system, you will be prompted with the normal installation/licensing agreement screens. You will then receive the dialog box below. To run the Light version, just click Next. To run the Full version, you will need to check the box to “Reset the print spooler to defaults”.

Note the Light version does not require a reboot but the Full version does. Again, do not run the Full version on a Print Server as it will delete all the printers.

Here are the details on what actually happens during each of these cleanups:

Light Mode

Set the print spooler service back to its defaults (automatically start, run as Local System, etc.)
Remove any dependencies that the spooler may have on 3^rd party services
Delete any print jobs from %windir%\system32\spool\printers (shd and spl files)
Turn on logging of print errors and warning to the event log (Printers -> File -> Server Properties -> Advanced Tab -> “Log spooler error events” and “Log spooler warning Events” will be checked)
Make sure the standard print monitors are present (USB, Local Port, and TCPIP) under [HKLM\CurrentControlSet\Control\Print\Monitors] (and WSD on 2008/Vista only)
Ensure that the winprint print processor is present for the architecture of the computer – for example: [HKLM\CurrentControlSet\Control\Print\Environments\Windows x64\Print Processors\winprint]
Start the print spooler service
If any of the core print spooler binaries are missing (spoolsv.exe, spoolss.dll, localspl.dll, win32spl.dll), the package attempts to copy that file from dllcache - if they aren’t present in dllcachce, we log that in the desktop log file
If ntprint.inf is missing, we log that to the desktop log file
If there is a bogus path for the spool directory DefaultSpoolDirectory under [HKLM\SYSTEM\CurrentControlSet\Control\Print\Printers], we log that information to the desktop log file

Full Mode

Does all of the Light steps first
Delete *.spl and *.shd files from a non-default spool folder
Delete *.spl and *.shd files from the default spool folder: %windir%\System32\spool\printers
Delete printer shares
Delete per-machine printers from [HKLM\SYSTEM\CurrentControlSet\Control\Print\Printers] (except on Vista do not delete "Microsoft XPS Document Writer" and “Fax”)
Delete per-machine connections from [HKLM\SYSTEM\CurrentControlSet\Control\Print\Connections] and the “Connections” key itself
Delete per-user connections under <USER HIVE>\Printers
Delete Monitors under [HKLM\SYSTEM\CurrentControlSet\Control\Print\Monitors] (except Local Port)
Delete each driver under [HKLM\SYSTEM\CurrentControlSet\Control\Print\Environments\Windows <arch>\Drivers\Version-3] (except on Vista don’t delete “Microsoft XPS Document Writer” and “Microsoft Shared Fax Driver”)
Vista: delete all files under “%windir%\System32\spool\drivers\<arch>\3” except for driver files associated with “Microsoft XPS Document Writer” and “Microsoft Shared Fax Driver”. Ignore subdirectories.
XP: delete the “%windir%\System32\spool\drivers” folder
Set back the defaults : [HKLM\SYSTEM\CurrentControlSet\Control\Print\Providers\LanMan Print Services\Servers] (AddPrinterDrivers=0)
Delete [HKLM\SYSTEM\CurrentControlSet\Control\Print\Providers\Internet Print Provider\Ports]
Add back these default values:
- HKLM\SYSTEM\CurrentControlSet\Control\Print\Monitors\USB Monitor
- HKLM\SYSTEM\CurrentControlSet\Control\Print\Monitors\Standard TCP/IP Port
- (XP) HKLM\SYSTEM\CurrentControlSet\Control\Print\Monitors\BJ Language Monitor
- (XP) HKLM\SYSTEM\CurrentControlSet\Control\Print\Monitors\PJL Language Monitor
- (Vista) HKLM\SYSTEM\CurrentControlSet\Control\Print\Monitors\WSD Port
- (If Fax driver was installed) HKLM\SYSTEM\CurrentControlSet\Control\Print\Monitors\Microsoft Shared Fax Monitor

As you can see the light mode of this tool is a great first pass at troubleshooting a myriad of Print Spooler issues, with minimal risk/downtime for your users. Give it a go and let us know how it works for you.

-Jeff Hagler

Useful WMIC Queries

Blake Morrison - MSFT — Fri, 17 Feb 2012 12:00:00 GMT

Hello AskPerf Blog Readers! This morning’s post is going to be more of a reference point for all those WMI junkies out there. Have you ever wanted to test WMI using the command line (outside of VBSCRIPT)? If so, then WMIC is the tool for you. In its simplest form, WMIC is a utility that allows you to interact with WMI from a WMI-aware command-line shell. All WMI objects and their properties, including their methods, are accessible through the shell, which makes WMIC an advanced systems management console.

This blog will assume that you already have a grasp of WMI and are looking for more WMI testing options via the Command Line. With that said, the following is a list of WMIC queries that you can run on your Workstations/Servers.

To execute these queries, run “WMIC” at a command prompt, followed by one of the following alias/es:

baseboard	get Manufacturer, Model, Name, PartNumber, slotlayout, serialnumber, poweredon
bios	get name, version, serialnumber
bootconfig	get BootDirectory, Caption, TempDirectory, Lastdrive
cdrom	get Name, Drive, Volumename
computersystem	get Name, domain, Manufacturer, Model, NumberofProcessors, PrimaryOwnerName,Username, Roles, totalphysicalmemory /format:list
cpu	get Name, Caption, MaxClockSpeed, DeviceID, status
datafile	where name='c:\\boot.ini' get Archive, FileSize, FileType, InstallDate, Readable, Writeable, System, Version
dcomapp	get Name, AppID /format:list
desktop	get Name, ScreenSaverExecutable, ScreenSaverActive, Wallpaper /format:list
desktopmonitor	get screenheight, screenwidth
diskdrive	get Name, Manufacturer, Model, InterfaceType, MediaLoaded, MediaType
diskquota	get User, Warninglimit, DiskSpaceUsed, QuotaVolume
environment	get Description, VariableValue
fsdir	where name='c:\\windows' get Archive, CreationDate, LastModified, Readable, Writeable, System, Hidden, Status
group	get Caption, InstallDate, LocalAccount, Domain, SID, Status
idecontroller	get Name, Manufacturer, DeviceID, Status
irq	get Name, Status
job	get Name, Owner, DaysOfMonth, DaysOfWeek, ElapsedTime, JobStatus, StartTime, Status
loadorder	get Name, DriverEnabled, GroupOrder, Status
logicaldisk	get Name, Compressed, Description, DriveType, FileSystem, FreeSpace, SupportsDiskQuotas, VolumeDirty, VolumeName
memcache	get Name, BlockSize, Purpose, MaxCacheSize, Status
memlogical	get AvailableVirtualMemory, TotalPageFileSpace, TotalPhysicalMemory, TotalVirtualMemory
memphysical	get Manufacturer, Model, SerialNumber, MaxCapacity, MemoryDevices
netclient	get Caption, Name, Manufacturer, Status
netlogin	get Name, Fullname, ScriptPath, Profile, UserID, NumberOfLogons, PasswordAge, LogonServer, HomeDirectory, PrimaryGroupID
netprotocol	get Caption, Description, GuaranteesSequencing, SupportsBroadcasting, SupportsEncryption, Status
netuse	get Caption, DisplayType, LocalName, Name, ProviderName, Status
nic	get AdapterType, AutoSense, Name, Installed, MACAddress, PNPDeviceID,PowerManagementSupported, Speed, StatusInfo
nicconfig	get MACAddress, DefaultIPGateway, IPAddress, IPSubnet, DNSHostName, DNSDomain
nicconfig	get MACAddress, IPAddress, DHCPEnabled, DHCPLeaseExpires, DHCPLeaseObtained, DHCPServer
nicconfig	get MACAddress, IPAddress, DNSHostName, DNSDomain, DNSDomainSuffixSearchOrder, DNSEnabledForWINSResolution, DNSServerSearchOrder
nicconfig	get MACAddress, IPAddress, WINSPrimaryServer, WINSSecondaryServer, WINSEnableLMHostsLookup, WINSHostLookupFile
ntdomain	get Caption, ClientSiteName, DomainControllerAddress, DomainControllerName, Roles, Status
ntevent	where (LogFile='system' and SourceName='W32Time') get Message, TimeGenerated
ntevent	where (LogFile='system' and SourceName='W32Time' and Message like '%timesource%') get Message, TimeGenerated
ntevent	where (LogFile='system' and SourceName='W32Time' and EventCode!='29') get TimeGenerated, EventCode, Message
onboarddevice	get Description, DeviceType, Enabled, Status
os	get Version, Caption, CountryCode, CSName, Description, InstallDate, SerialNumber, ServicePackMajorVersion, WindowsDirectory /format:list
os	get CurrentTimeZone, FreePhysicalMemory, FreeVirtualMemory, LastBootUpTime, NumberofProcesses, NumberofUsers, Organization, RegisteredUser, Status
pagefile	get Caption, CurrentUsage, Status, TempPageFile
pagefileset	get Name, InitialSize, MaximumSize
partition	get Caption, Size, PrimaryPartition, Status, Type
printer	get DeviceID, DriverName, Hidden, Name, PortName, PowerManagementSupported, PrintJobDataType, VerticalResolution, Horizontalresolution
printjob	get Description, Document, ElapsedTime, HostPrintQueue, JobID, JobStatus, Name, Notify, Owner, TimeSubmitted, TotalPages
process	get Caption, CommandLine, Handle, HandleCount, PageFaults, PageFileUsage, PArentProcessId, ProcessId, ThreadCount
product	get Description, InstallDate, Name, Vendor, Version
qfe	get description, FixComments, HotFixID, InstalledBy, InstalledOn, ServicePackInEffect
quotasetting	get Caption, DefaultLimit, Description, DefaultWarningLimit, SettingID, State
recoveros	get AutoReboot, DebugFilePath, WriteDebugInfo, WriteToSystemLog
Registry	get CurrentSize, MaximumSize, ProposedSize, Status
scsicontroller	get Caption, DeviceID, Manufacturer, PNPDeviceID
server	get ErrorsAccessPermissions, ErrorsGrantedAccess, ErrorsLogon, ErrorsSystem, FilesOpen, FileDirectorySearches
service	get Name, Caption, State, ServiceType, StartMode, pathname
share	get name, path, status
sounddev	get Caption, DeviceID, PNPDeviceID, Manufacturer, status
startup	get Caption, Location, Command
sysaccount	get Caption, Domain, Name, SID, SIDType, Status
sysdriver	get Caption, Name, PathName, ServiceType, State, Status
systemenclosure	get Caption, Height, Depth, Manufacturer, Model, SMBIOSAssetTag, AudibleAlarm, SecurityStatus, SecurityBreach, PoweredOn, NumberOfPowerCords
systemslot	get Number, SlotDesignation, Status, SupportsHotPlug, Version, CurrentUsage, ConnectorPinout
tapedrive	get Name, Capabilities, Compression, Description, MediaType, NeedsCleaning, Status, StatusInfo
timezone	get Caption, Bias, DaylightBias, DaylightName, StandardName
useraccount	get AccountType, Description, Domain, Disabled, LocalAccount, Lockout, PasswordChangeable, PasswordExpires, PasswordRequired, SID

In troubleshooting WMI issues here on the Performance team, I often run the following commands to test WMI locally and remotely:

WMIC CPU GET NAME

WMIC /NODE:SERVERNAME CPU GET NAME

Additional Resources

-Blake Morrison

Measuring Disk Latency with Perfmon

Blake Morrison - MSFT — Thu, 16 Feb 2012 17:05:51 GMT

Hello AskPerf folks! This is just a quick blog post to inform you of a great posting from one of our Disk Experts on our Core team. It is very informative and talks about measuring Physical Disk IO Latency with Perfmon. Check it out!

Measuring Disk Latency with Windows Performance Monitor (Perfmon)

http://blogs.technet.com/b/askcore/archive/2012/02/07/measuring-disk-latency-with-windows-performance-monitor-perfmon.aspx

-Blake Morrison

RDS Multiple Server Access

Blake Morrison - MSFT — Tue, 14 Feb 2012 12:00:00 GMT

Good morning AskPerf! Nabarun here from the Windows Performance Team to discuss the method of allowing RDP access to multiple servers in a flash. System administrators often want to know how to enable RDP access throughout the domain. The uninspired answer is to go around to every machine in the domain and add users and groups to the local “Remote Desktop Users” group.

This is the most restrictive and conservative approach to achieve the solution, reinforcing the idea that administrators should enable RDP access only to servers where it is necessary.

There are still situations where administrators need to allow domain users and groups RDP access to a large number of systems.

For RDP access, the following Security Setting must be configured:

The user or group must also have the “Allow User Access” permission on the “RDP-Tcp” connection. By default, the local group “Remote Desktop Users” has access to both items above; so adding any user to “Remote Desktop Users” group ensures RDP access. Click here for another blog on the topic.

Myth - Adding a user to the “AD Users and Computers\Builtin\Remote Desktop Users” group does NOT allow RDP access to all servers throughout the domain! This is just a local group for the DC.

There are several different methods to add users and groups to the local Remote Desktop Users group for client systems or member servers.

Method 1 (Startup script)
Add the following command to a startup script for all servers where RDP access is required:

NET LocalGroup "Remote Desktop Users" /ADD "domain\user or group name"

Method 2 (“Restrictive groups” GPO)

Scripts are generally the least preferred method of achieving configuration if there is an easier, scalable way to enable RDP access for groupings of systems throughout the domain. This can be achieved with the “Restrictive Groups” group policy.

This policy allows us to configure group memberships on client computers or member servers. We can add domain accounts or groups to local groups on systems within the domain.

In this example, we will add the domain group DomainRDPGroup to the local Remote Desktop Users group on all client computers in the domain in one shot:

1. Create a new group named DomainRDPGroup (configure it as a Global Security group) and then add the users who need RDP access to the systems.

2. Open Group Policy Management Console, and right click on the Default domain policy, then select Edit - this should open the Group policy management editor

NOTE: Keep in mind this is only an example and by editing the default domain policy you will be adding the DomainRDPGroup to the Remote Desktop Users group on every machine in your domain – including your domain controllers. It’s generally better to create a separate policy and link it to a specific OU that contains the systems we need to enable RDP access to.)

3. Right-click “Restricted Groups” from Computer Configuration | Policies | Windows Settings | Security Settings, and select “Add Group”

4. Type in or browse to the group we created in step 1 named “DomainRDPGroup”, then click OK.

After this, the “DomainRDPGroup Properties” will appear with an upper and a lower section. The top section allows you to modify the group membership of the group. Since we already added users to the DomainRDPGroup group, we can ignore this section in the policy.

NOTE: Entering any usernames as part of the policy setting will replace any existing group membership for this DomainRDPGroup. If we were to click Add and type user3 here, it would remove all of the users from DomainRDPGroup, and only leave user3. Leaving this section blank means it will use the existing group membership of DomainRDPGroup in Active Directory.

5. In the bottom section, click “Add” and type in the name of the local group; in this case, it is “Remote Desktop Users.”
This adds the entries entered in the section “This group is member of” into the local “Remote Desktop Users” group on each computer where the policy is applied.

Where the policy is applied depends on where the group policy is linked in the Domain. (Site, Domain, or Organizational Unit).This feature is non-intrusive and will not replace or remove the existing group membership of the Remote Desktop Users group on the target system. It simply adds additional members to the group.

More information about Restrictive Groups is available on TechNet.

7. Run “gpupdate/force” on the client computer. This will force the policy to apply immediately instead of waiting for the group policy processing interval to complete.

The following screenshot shows the local group “Remote Desktop Users”, which now includes our domain level group DomainRDPGroup. It also retains existing group members LocalUser1 and LocalUser2 which were added manually on the client computer.

This is a dynamic and seamless procedure of managing remote desktop group memberships at the Admin level without having to access the client computer/member server directly. Good luck!

-Nabarun Chakraborty

Using Resource Monitor to Troubleshoot Windows Performance Issues Part 2

Blake Morrison - MSFT — Wed, 08 Feb 2012 12:00:00 GMT

Hello again AskPerf Blog Readers! Leonard back again to continue Part 2 of our Resource Monitor topic. Today we are going to cover the System Health Report, aka System Diagnostics Report. This report is a combination of data generated through Perfmon, Kernel Event Tracing (.EVT), and WMI queries. There are 2 ways to gather and view the data:

1. Automatically though Control Panel | Performance Information and Tools | Advanced tools | Generate a system heath report (the report will be viewed through a Resource and Performance Monitor window).

2. Manually though Perfmon: To do this run, Perfmon and expand Data Collect Sets, then select System. On the right pane right click on System Diagnostics and choose Start. The view will change to System Diagnostics selected on the left and all of the data being gathered on the right. The data is stored in the “C:\PerfLogs\System\Diagnostics\<HOSTNAME>-Date” folder. On the left under Reports, there will be a System Diagnostics report which is saved in HTML format. After 60 seconds, selecting it will display the same data as Resource and Performance Monitor window. Each time a report is generated, it will be saved here.

TIP you can also kick it off by running “Perfmon /report”

Here are all of the categories that are available:

Expanding the view on any of these will display additional information and offer additional subcategories. Selecting the icon that looks like a page will bring up a tree view list which is the most efficient way to find something in the report.

The report provides 2 types of information:

1. Software and hardware configuration checks reporting the values found, and providing errors or warnings about problems or non-optimally configured settings

2. List of disk, network, process and memory activities

The configuration checks can be useful for checking to confirm that Windows is configured with recommended settings. Here is an example view where Windows Update is not configured and AV is not installed. It also shows that the disk SMART table reports that the disk is operating normally. This is a useful check to predict if a disk will fail before it fails:

Here we can see one of the lists that are generated. In this case, it is the hot files list which shows the files with the most IO and what process is generating the IO. In this example, I was generating a test.zip file using Windows built in compression which uses the system process:

With that, we have come to the end of our two part blog posts on Resource Monitoring. Now go forth and start resolving those High CPU/MEMORY/DISK/NETWORK related issues!!!

Additional Resources

-Leonard Severt

WMIDiag 2.1 is here!

Blake Morrison - MSFT — Fri, 03 Feb 2012 12:00:00 GMT

Good morning AskPerf blog readers! Subheet here from the Windows Performance Team. It’s been a while since I’ve written a BLOG, and am really excited about this one. This time, I’m back with our brand new, much anticipated, WMI troubleshooting tool, WMIDIAG 2.1.

The WMI Diagnosis Tool is a VBScript based-tool for testing, validating, and analyzing WMI installation/issues. The tool collects data from WMI installations on all Microsoft Operating Systems at any or no service pack level.

WMI Diagnostics 2.1 requires you to have Local Administrator rights as well as Windows Script Host (WSH) enabled.

To download this tool, please click here.

After you download WMIDiag.exe, run it and extract the files to a local folder. If you double-click WMIDiag.vbs, the following message will appear:

If you want to see its activity, then you would run “cscript WMIDiag.vbs” from the command prompt.

WMIDIAG can be run from Windows Explorer, or from the command line. Each time it runs, the WMI Diagnosis Tool creates the following three files in the %TEMP% directory:

.LOG file containing all the WMI Diagnosis Tool activity as well as a WMI report at the end
.TXT file containing the WMI Diagnosis Tool report
.CSV file containing statistics that can be used to measure trends and issues

When the WMI Diagnosis Tool terminates, the ERRORLEVEL environment variable is set to one of the following values:

0 = SUCCESS

WSH has a script execution timeout setup (in machine or system environment)
Machine reports suspicious improper shutdowns
User Account Control (UAC) status is reported (Vista and above)
Local account token filter policy is reported (Vista and above)
Unexpected binaries in the WBEM folder
The Windows Firewall is enabled
Some WMI service installed in the machine are dependent on the WMI service (i.e. "SMS Agent)
WMI ADAP has a status different than 'running'
Some WMI namespaces require a packet privacy encryption for a successful connection
Some WMI permanent subscriptions or timer instructions are configured
Some information about registry key configurations for DCOM and/or WMI was reported

1 = ERROR

System32 or WBEM folders are not in the PATH
WMI system file(s)\ repository is/are missing
WMI repository is inconsistent (XP SP2, 2003 SP1 and above)
DCOM is disabled
WMI service is disabled
The RPCSS and/or the WMI service(s) cannot be started
WMI DCOM setup issues
Expected default trustee or ACE has been removed from a DCOM or WMI security descriptor
The ADAP status is not available
One or more WMI connections failed
Some GET operations\WMI class MOF representations\WMI qualifier retrieval operations failed
Some critical WMI ENUMERATION operations\WMI EXECQUERY\WMI GET operations failed
Some WRITE operations in the WMI repository\PUT\DELETE operations failed
One of the queries of the event log entries for DCOM, WMI and WMIADAPTER failed
Some critical registry key configurations for DCOM and/or WMI were reported

2 = WARNING

System32 or WBEM folders are further in the PATH string than the maximum system length
System drive and/or Drive type reporting are skipped
DCOM has an incorrect default authentication level (other than 'Connect')
DCOM has an incorrect default impersonation level (other than 'Identify')
WMI service has an invalid host setup
WMI service (SCM configuration) has an invalid registry configuration
Some WMI components have a DCOM registration issue
WMI COM ProgID cannot be instantiated
Some WMI providers have a DCOM registration issue
Some dynamic WMI classes have a registration issue
Some WMI providers are registered in WMI but their registration lacks a CLSID
Some WMI providers have a correct CIM/DCOM registration but the corresponding binary file cannot be found
A new ACE or Trustee with a denied access has been modified to a default trustee of a DCOM or WMI security descriptor
An invalid ACE has been found for an actual DCOM or WMI security descriptor
WMI ADAP never ran on the examined system
Some WMI non-critical ENUMERATION operations failed\skipped
Some WMI non-critical EXECQUERY operations failed\skipped
Some non-critical WMI GET VALUE operations failed
Some WMI GET VALUE operations were skipped (because of an issue with the WMI provider)
The WRITE operations in the WMI repository were not completed
The information collection for the DCOM, WMI and WMIADAPTER event log entries was skipped
New event log entries for DCOM, WMI and WMIADAPTER were created during the WMI Diagnosis Tool execution
Some non-critical registry key configurations for DCOM and/or WMI were reported

3 = Command Line Parameter errors

4 = User Declined (Clicked the Cancel button when getting a consent prompt)

WMIDiag is started on an unsupported build or OS version
WMIDiag has no Administrative privileges
WMIDiag is started in Wow environment (64-bit systems only)

When you run the WMI Diagnosis Tool via command line:

C:\>CSCRIPT WMIDiag.vbs

The generated report “%TEMP%\WMIDIAG-V2.1_WIN7_.CLI.SP1.64_MYPC_2012.02.02_12.53.07-REPORT.TXT“ contains two types of figures:

WARNING - Information that is useful if certain actions are executed
ERROR - Problems that need to be solved to avoid errors reported by WMI

WMI DIAG 2.1 FAQ:

1. Where can I get the WMI Diagnosis Tool?

The WMI Diagnosis Tool can be downloaded from the Microsoft Download Center at http://www.microsoft.com/download/en/details.aspx?id=7684. More information about the WMI Diagnosis Tool usage can be found in the document (WMIDiag.doc) which comes along with the download.

2. Is it possible to “officially” engage Microsoft for feedback on this tool?

There is no official support for WMI Diagnosis Tool. However, feedback for the tool is welcome and can be sent to WMIDiag@microsoft.com.

3. Can the WMI Diagnosis Tool diagnose a remote computer?

The WMI Diagnosis Tool is not designed to diagnose remote computers. This is due to the fact that WMI remote access is mainly based on the WMI infrastructure. Because the aim of WMI Diagnosis Tool is to diagnose WMI, the WMI Diagnosis Tool does not use WMI to perform its core operations. That’s why the WMI Diagnosis Tool must be run locally. However, the WMI Diagnosis Tool can be deployed remotely using Group Policy, Systems Management Server (SMS), or Microsoft Operations Manager (MOM) via a Management Pack. With Windows Vista, the WMI Diagnosis Tool can also be remotely executed through WinRM/WinRS, provided you configure and enable these features (WinRM/WinRS are not enabled by default). Microsoft SysInternals tool PSEXEC.EXE can also be used.

4. Does the WMI Diagnosis Tool fix problems it discovers?

No. The WMI Diagnosis Tool executes in read-only mode. Even though the WMI Diagnosis Tool diagnoses the situation and provides procedures to fix problems, at no time does the tool automatically fix a problem. This is by design, because the correct repair procedure depends on the context, the usage, and the list of applications installed on the computer.

I hope this new tool will help you identifying potential WMI issues in your environment. Don’t forget to read the support document (WMIDiag.doc) included in the WMIDIAG 2.1 download. Until my next post, take care!

-Subheet Rastogi

Using Resource Monitor to Troubleshoot Windows Performance Issues Part 1

Blake Morrison - MSFT — Wed, 01 Feb 2012 12:00:00 GMT

Hello AskPerf! Leonard with the Performance Team here to discuss the Resource Monitor tool and we can use it to troubleshoot Windows Performance issues. In this blog, (the first of 2 on the subject of underutilized tools) I will discuss Resource Monitor which is available on both client and server versions of Windows starting with Windows Vista. Resource Monitor can be launched from the advanced tools tab in “Performance Information and Tools”, which is located in Control Panel. It can also be launched directly by running Resmon.exe.

Resource Monitor is a method of viewing Perfmon data. In fact, Resource Monitor is composed of Perfmon data combined with Windows Event Tracing data. You can view this tracing session by launching Perfmon, expanding Data Collector Sets, then select Event Tracing Sessions. There you will see a session called WDC.GUID (the GUID will vary). You can confirm this provides the data for Resource Monitor by observing that this trace is only running when Resource Monitor is running. Also, when it is running, you can view the channels that provide the data. Launching Resource Monitor will also launch a background process of Perfmon to act as a data source.

Resmon will show the window below on first launch. Each new launch will show the view as configured when Resmon was closed.

There are 5 tabs to choose from. The overview tab gives a summary of the other ones. The main tabs are CPU, Memory, Disk and Networking. In each of the tabs the windows on the left can be collapsed, expanded and resized. It is also possible to filter each view by the process, for example you are only interested in seeing the activity for Explorer, check the box for that process and the bottom window will only show the activity for that process. With no processes selected, the bottom windows will show activity for all active processes. The graphs on the right can be resized between small, medium and large, but I would recommend keeping them at the default large setting. The numeric scale for the graphs will change as activity changes.

My Favorite features

The memory tab has one unique graph that provides a quick view of what physical memory is being used for.

It is easy to see the total physical memory and what it is being actively used along with showing what is hardware reserved. Hardware Reserved represents physical memory addresses that have been reserved by hardware (generally busses like PCI or video cards) and is not available for Windows to use. It is usually small on x64 systems (except servers that do memory mirroring) but can be several 100MB up to 1GB on x32 systems. This means a 4GB x86 system can have only 3 GB of accessible memory.

The network tab is useful in that it not only shows the process that is generating activity, but the IP address it is connected to.

I recently had an issue where the system process was showing high CPU activity on a Windows 2008 Server. Two of the things that run in system are the SMB and SMB2 processes. I suspected that the high CPU was due to network activity and was a load based problem and not a problem with a process. To confirm that was the cause, I used Process Explorer to determine the threads that were running in the system process. I confirmed that there were 15+ SMB and SMB2 threads that were always the highest consumer of CPU. I then ran Resmon and looked at all of the IP addresses that were associated with system. We identified a management server that was receiving a lot of data. Based on that information, we were able to narrow down the problem to the request coming from that server. While the problem could have been identified using different tools, Resmon provided the most efficient way to identify the problem.

I hope this overview of Resource Monitor will make it one of the tools you use the next time you need to look at performance data or activity on the system.

Additional Resource

What’s New in Performance and Reliability Monitoring?

-Leonard Severt

Real life SQL Working Set Trimming issue

Blake Morrison - MSFT — Wed, 25 Jan 2012 12:00:00 GMT

Good morning AskPerf! Leonard here to chat about a performance issue we often see on the Windows performance team surrounding SQL and Working Set Trimming. I recently worked an issue on a 2003 SP2 x64 Server, running SQL 2005, that was experiencing periods of slow performance and filling up the SQL log with the following error:

A significant part of sql server process memory has been paged out. This may result in performance degradation.

This error is covered in detail in the following article:

How to reduce paging of buffer pool memory in the 64-bit version of SQL Server

http://support.microsoft.com/kb/918483

This error is logged when the working set of SQL is trimmed, meaning it is paged out to disk. The working set of a program is just the memory it is using. Normally working set trimming isn’t necessarily a bad thing. It’s the way Windows takes memory from one program that hasn’t been used most recently (and might never be used again) and gives it to other programs. But for SQL to operate efficiently, it must keep a large part of its data in memory. When it gets trimmed, then SQL operations can take a significantly longer time to complete. Therefore we needed to determine what was using a large amount of memory on the system causing the problem. For almost all Windows performance issues we gather Perfmon data, as I did in this case. We had it capturing a circular log, and stop it after the SQL error occurred. I then produced a summary of the Perfmon logs and the following data stood out:

I could see a SIGNIFICANT range between Minimum and Maximum in Available Bytes, Private Bytes, Working Set, and Cache Bytes. This was occurring when there should have been a somewhat constant work load and therefore memory usage should not have varied greatly. The SQLserver process was the only process with significant working set values. When discovering something in the numbers like this, the next step is to see how some of the important counters change together over time. Looking at a visual graph is the best way to see that relationship.

Here we see a pattern where Available MB drops below 100 MB ~ every 2 hours and 10 min and working set is trimmed; mostly from SQL since it is the largest process:

Looking at the one where SQL gets trimmed to 2 GB at ~ 3:50 AM. I added in Cache bytes since we know it varies. I also wanted to know what processes were starting during this period. My favorite counter for that is Process\Elapsed Time. If you scale it to the graph, it is easy to see anything with a sharp angle (meaning it would intersect with the bottom of the graph) or that starts and stops. I removed all of the ones that were flat and was left with the following:

We can see above that Cache Bytes grow to 15 gig when all of this occurs. The processes that start at this time were bpcd and dbbackex, and the bphdb was restarted (these are all backup processes). Here is one with the bpcd process selected so we can see where it is running:

Zooming out we see the pattern repeats with a different backup process selected. This confirms that the cause of the working set trimming is always the same backup process:

Conclusion: The SQL backup (Veritas Netbackup) was causing cache bytes to grow up to ~15 GB and Windows was trimming SQL working set memory to give memory back to cache. This can be a common problem on 64 bit Windows where cache used for file IO can grow large enough to impact Windows performance. There were 2 possible solutions to this:

Solution 1

Implement SQL lock pages in memory. When memory is locked by SQL, it prevents Windows from taking that memory from SQL. The down side to that is Windows memory management might not be able to respond to even smaller request for memory from programs that need it. Because of this, only use lock pages in memory when need.

Solution 2

Another option would be to implement the Windows Dynamic Cache service. This is a service that was developed in-house to use Windows memory management API’s to control the amount of cache memory that is used on Windows. There are a number of registry keys that can be set to control the behavior and therefore it can be adapted to different issues and Windows configurations.

On this particular case, we decided to implement the Dynamic Cache service. To download the Microsoft Windows Dynamic Cache Service, check the following link:

http://www.microsoft.com/download/en/details.aspx?displaylang=en&id=9258

After it was installed, we set the following registry key:

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\DynCache\Parameters]

RegValue: MaxSystemCacheMBytes

Type: REG_DWORD

Value: 1000

Setting this registry key allowed us to set a limit on cache memory to 1GB. We choose this value because it would provide some cache, but was small enough to not impact SQL.

Other possible values for this registry key are:

0 = Limit to 90% of Physical RAM (default)

1-99 = Limit the maximum size of the System File Cache to this percentage of Physical RAM

> 200 = Limit the maximum size of the System File Cache to x Mbytes

Once this was service was implemented, we monitored the system for a week. After this time, we confirmed that both SQL and the backup processes were stable with no performance related issues.

Hopefully this post will help you tackle those fun Working Set/Cache issues on your Windows Servers.

Additional Resources

-Leonard Severt

Troubleshooting High CPU Utilization issues using Tracelog.exe

Blake Morrison - MSFT — Fri, 20 Jan 2012 12:00:00 GMT

Good day AskPerf! Vinod Rawat here to discuss/demonstrate the benefits of using the Tracelog.exe utility to troubleshoot High CPU issues. Tracelog.exe is a command line utility that allows us to start/stop or enable trace logging, and offers the following features:

Starts and stops trace sessions, including private trace sessions, NT Kernel Logger trace sessions, and Global Logger trace sessions
Configures and changes the properties of trace sessions
Enables and disables trace providers
Flushes trace session buffers
Lists running (real-time) trace sessions
Lists registered trace providers
Measures time spent in deferred procedure calls (DPCs) and interrupt service routines (ISRs)

NOTE Tracelog.exe is included in the tools\tracing\<Platform> subdirectory of the Windows Driver Kit (WDK), where <Platform> is either i386, amd64, or ia64.

In this post, I am going to talk about troubleshooting a High CPU issue, where no user-mode processes are visibly spiking the CPU. With that, let’s get started!

The first thing you will want to do is download Process Explorer and run it on the affected workstation/server. In this example, we see that Interrupts and its corresponding CPU usage shown below:

You can also add the following Performance Monitor Counters and see the same behavior:

Processor: % Interrupt Time

Processor: %DPC Time

Processor: %Privilege Time

This is where tracelog.exe comes in handy. Open an Elevated Command Prompt, and browse to the folder that includes the tracelog.exe utility (see Note above). During the high interrupt time we can capture DPC/ISR ETL tracing with the following syntax:

tracelog -start -f test.etl -dpcisr -UsePerfCounter -b 64

Switches:

-start = Starts up the test.etl trace session

-f = Log to file <name>

-dpcisr = Enable kernel events for DPC/ISR analysis

-UsePerfCounter = Use Perf Counter clock

-b 64 = Sets buffer size to <n> Kbytes

NOTE When tracing DPCs and ISRs, always add the -UsePerfCounter parameter to the command. The system timer resolution is too low to measure the time spent in these activities. Tracerpt.exe, the tool that formats DPC/ISR events, requires the performance counter clock values for its reports. (Tracerpt is included in Windows XP and later versions of Windows.)

Let the tracelog.exe run for roughly 30seconds to 1 minute, then stop the tracing with following syntax:

tracelog -stop

Now we can create a report using the Tracerpt.exe tool with the following command:

tracerpt test.etl -report dpcisr.html -f html

These switches create the report file dpcisr.html in HTML format.

Now comes the fun part (The following is just a descriptive example and what I experienced on my machine).

1. Open the html file you created above

2. Locate the DPC/ISR section in the report:

3. Depending on your scenario, focus on either “Distribution of DPC execution times” or “ISR processor utilization” columns:

4. Sort by the Percent column and you will see the highest consumer (dxgkrnl.sys) at top:

Dxgkrnl.sys is at top taking highest-but-nominal ISR processor time on my machine above (which is obviously normal).

For those who want to go deeper than this: When a culprit driver’s ISR routines are keeping the CPU busy, you can further zoom in and find out the exact range of time these routines are spending in:

Focus on Lower Bound and Upper Bound range and the corresponding Percent. More than 88% (61.66 + 26.59 = 88.25%) count is taking more than 25 microseconds. Microsoft recommends that DPCs should not run longer than 100 microseconds and ISRs should not run longer than 25 microseconds. ISR routines belonging to the driver above (obscured) have exceeded this value, thus you know how to pin-point the culprit and then check the concerned ISR routines’ time taken.

Happy tracing!

Additional Resources:

-Vinod Rawat

System Data Collector Sets fail on an upgraded 2008 / 2008 R2 DC

Blake Morrison - MSFT — Fri, 13 Jan 2012 12:00:00 GMT

Hello Askperf! Shamesh Pillai here to discuss an interesting issue I recently worked. On Microsoft Windows Server 2008, 2008 R2 Domain Controllers, Perfmon may fail when starting a System Data Collector Set. This includes the Active Directory Diagnostics, System Diagnostics, and System Performance Perfmon logging.

When we start any of the System Data Collector Sets, the following error may appear and/or the Data Collector Set may freeze:

Logon failure: the user has not been granted the requested logon type at this computer

When this fails, the following Events will be logged in the TaskScheduler event log:

Log Name: Microsoft-Windows-TaskScheduler/Operational
Source: Microsoft-Windows-TaskScheduler
Date: 11/30/2011 6:36:18 AM
Event ID: 101
Task Category: Task Start Failed
Level: Error
Keywords: (1)
User: SYSTEM
Computer: <Computer Name >

Description:
Task Scheduler failed to start "\Microsoft\Windows\PLA\System\{CFCD20D6-D2CE-42D3-A9CB-9916E676DE02}_System Diagnostics" task for user "<Username>". Additional Data: Error Value: 2147943785.

Log Name: Microsoft-Windows-TaskScheduler/Operational
Source: Microsoft-Windows-TaskScheduler
Date: 11/30/2011 6:36:18 AM
Event ID: 104
Task Category: Logon failure
Level: Error
Keywords:
User: SYSTEM
Computer: <Computer Name>
Description:
Task Scheduler failed to log on "<UserName>" . Failure occurred in "LsaLogonUser”. User Action: Ensure the credentials for the task are correctly specified. Additional Data: Error Value: 2147943785.

While troubleshooting the issue, I observed that of all the servers experiencing this behavior, all were Domain Controllers that were upgraded from a Windows Server 2003 Domain Controller. Interestingly though, the issue does not happen on a freshly installed Microsoft Windows 2008, 2008 R2 Domain Controller, or if we upgrade a Member server. In my testing, we observed that “User Defined” Sets were not affected by this problem.

In Microsoft Windows Server 2008 and later operating systems, Perfmon uses Task Scheduler in the background. When we start a System Data Collector Set, it launches Taskeng in the current user context. To launch the job, the user needs to be included in the “Log on as a batch job” User Rights Assignment Policy.

We checked the “Log on as a batch job” Policy and discovered that the “Performance Log Users” group was not included. As soon as we added this group back to the Policy, we were able to successfully start our System Data Collector Sets.

By default, the “Performance Log Users” group is expected to have the “Log on as a batch job” user right. However, when the 2003 Domain Controller was upgraded to Server 2008, the “Performance Log Users” group did not get added to this Policy.

With that, we have concluded our post for today. Take care!

Additional Resources

Enable Logging for Performance Log Users Group Members

-Shamesh Pillai

Case of the Windows Installer installation failure and AppCompat shim

Blake Morrison - MSFT — Fri, 06 Jan 2012 12:00:00 GMT

Good morning AskPerf! Anshuman Ghosh here to chat about an issue I recently worked where a specific Windows Installer package failed to install on a Windows 2008 R2 Server. Basic Windows Installer troubleshooting took place, including the ability to install other .msi packages successfully. I then enabled Verbose MSI logging per KB223300:

[HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows\Installer]

Reg_SZ: Logging

Value: voicewarmupx

and the following was observed:

I used the Err utility to convert the error code:

C:\>err 0x8002801C

# for hex 0x8002801c / decimal -2147319780 :

TYPE_E_REGISTRYACCESS winerror.h

# Error accessing the OLE registry.

# 1 matches found for "0x8002801C"

This error translates to “Error accessing the OLE registry”. From the msi verbose log, we know that the error came while executing the function call DoRegisterTypeLib in a custom action for msxml3.dll in the SYSWOW64 folder. With this information, we captured Process Monitor logs from a working and non-working machine and observed the following:

The registry entry in question, [HKCR\TypeLib\{F5078F18-C551-11D3-89B9-0000F81FE221}\3.0\0\win32], is being accessed by the 32bit process on the non-working machine. If you drill into the stack trace of the highlighted line, you can see the RegisterTypeLib function call:

The handle to the reg key is then closed and there is nothing else significant after the RegQueryKey operation above. On a working machine, we see a significant difference as it continues to query the security and subkeys:

The thread stack for the highlighted line shows the following:

It would appear that the specific function call is being shimmed by appcompat. So, why is the shimming not occurring on the non-working machine? The answer is at the beginning of the log, when the apphelp.dll loads in the msiexec process. The following registry key is checked:

[HKLM\SOFTWARE\Policies\Microsoft\Windows\AppCompat]

DisableEngine=

And sure enough, it was set to a 1. Application compatibility engine can be turned off by either setting the above registry entry to 1 manually, or by configuring the “Turn off Application Compatibility Engine” group policy setting under “Computer Configuration | Administrative Templates | Windows Components | Application Compatibility.”

Additional Resources:

DisableEngine

-Anshuman Ghosh

Wallpaper Deployment Troubleshooting

Blake Morrison - MSFT — Tue, 13 Dec 2011 12:00:00 GMT

Hello AskPerf! Deepak Kumar here to discuss an emerging issue we’ve been seeing on the front lines that surround Wallpaper deployment to Windows Desktops. We’re going to primarily focus on Windows 7, and may sprinkle a little XP in. With that said, let’s dig in!

Lots of customers like to force Customized Wallpaper to their user’s machines. Whether this be mandatory or a start screen for new users. When configuring the policies to be applied, it is extremely important to not overlook the fine print on what they actually accomplish. Here are the policies that control Desktop Wallpaper:

User Configuration | Administrative Templates | Desktop | Desktop | “Desktop Wallpaper”

Specifies the desktop background ("wallpaper") displayed on all users' desktops.

This setting lets you specify the wallpaper on users' desktops and prevents users from changing the image or its presentation. The wallpaper you specify can be stored in a bitmap (*.bmp) or JPEG (*.jpg) file.

To use this setting, type the fully qualified path and name of the file that stores the wallpaper image. You can type a local path, such as C:\Windows\web\wallpaper\home.jpg or a UNC path, such as \\Server\Share\Corp.jpg. If the specified file is not available when the user logs on, no wallpaper is displayed. Users cannot specify alternative wallpaper. You can also use this setting to specify that the wallpaper image be centered, tiled, or stretched. Users cannot change this specification.

If you disable this setting or do not configure it, no wallpaper is displayed. However, users can select the wallpaper of their choice.

Also, see the "Allow only bitmapped wallpaper" in the same location, and the "Prevent changing wallpaper" setting in User Configuration\Administrative Templates\Control Panel.

Note: This setting does not apply to remote desktop server sessions.

User Configuration | Administrative Templates | Control Panel | Personalization | “Prevent changing desktop background”

Prevents users from adding or changing the background design of the desktop.

By default, users can use the Desktop Background page in the Personalization or Display Control Panel to add a background design (wallpaper) to their desktop.

If you enable this setting, none of the Desktop Background settings can be changed by the user.

To specify wallpaper for a group, use the "Desktop Wallpaper" setting.

Note: You must also enable the "Desktop Wallpaper" setting to prevent users from changing the desktop wallpaper. Refer to KB article: Q327998 for more information.

Also, see the "Allow only bitmapped wallpaper" setting.

After you set one or both of the above policies, you deploy them out to your users. There may be times when the Wallpaper does not display. If that occurs, follow these steps:

Step 1

Determine which nodes/machines do not see the Wallpaper which was deployed. Categorize these machines by the following:

Operating System (Windows XP, Vista, 7)
The OU they participate in

Step 2

Confirm that your policies are set correctly. If some machines in the OU do not see the Wallpaper, then chances are the policy did not get applied. To confirm that the policy got applied, simply capture a “gpresult /z” output from the machine/machines in question, then check the policy.

Step 3

Is the Wallpaper accessible? Can the user access the JPG or BMP locally and/or on your network share? Obviously, the correct permissions should be validated if the Wallpaper resides on a network share.

Step 4

Is the registry key set correct? Since Wallpaper is a user specific setting/policy, you should check if the following registry location reflects the Wallpaper file/path you specified in your policy:

[HKEY_CURRENT_USER\Control Panel\Desktop]

Wallpaper = CORP.BMP or \\SERVER1\SHARE\CORP.BMP

Step 5

Have you checked the Wallpaper style? Interestingly enough, this becomes a primary suspect when dealing with an OU that contains a mixture of Windows XP and later Operating Systems. In Windows 7, you can find Fill and Fit as two additional wallpaper styles compared to Windows XP. See the screenshots below:

Windows XP does not have the option to Fill or Fit Desktop Wallpaper. So, in a mixed OS environment, this is something you will want to keep an eye out for. The obvious fix is to select any other style, excluding Fill or Fit. The registry location for this setting is as follows:

[HKEY_CURRENT_USER\Control Panel\Desktop]

WallpaperStyle = 10 (Fill), 6 (Fit), 2 (Stretch), 0 (Tile), 0 (Center)

Step 6

Some users may be smart enough to set their wallpaper via Image Preview. Why does this occur? Well, because the policy “Prevent changing desktop background” prevents users from changing the wallpaper via Desktop Background in Personalization. Image Preview uses a different method, thus by passing the policy. To get around this, you will need to Enable the “Active Desktop Wallpaper” policy noted in http://support.microsoft.com/kb/327998.

If all else fails

If your Desktop Wallpaper still does not show, then try the follow options:

Check the following hotfix - http://support.microsoft.com/kb/977944
Check the Application and/or System logs for any application crashes
Login to the same machine with a different user account and check behavior
On Windows XP & Vista, you will not see GPO Wallpaper via RDP connection; however, this is now available in Windows 7
Use the Process Monitor tool to collect the logs while you attempt to apply desktop

As you can tell, there are many road blocks that can cause Desktop Wallpaper to not appear correctly. Following the steps above should help resolve any Wallpaper issues you encounter in the future.

Additional Resources:

-Deepak Kumar

Default Print Device Selection Behavior in Windows

Blake Morrison - MSFT — Tue, 22 Nov 2011 12:00:00 GMT

Good Morning AskPerf Readers! Our theme today is printing, specifically Default Printer selection behavior. We regularly get asked the question on what causes the default printer to change on a Windows host. Understanding the reasons why this change occurs can alleviate a lot of the frustration end users experience when it happens, as well as provide helpdesk staff an easy-to-share solution to the problem.

When installing a new print device (or software that may install a software based printer), the default printer may change for the current user without prompting the user if the current default printer has been deleted. This can happen if the new installation package deletes the current default printer prior to installing the new one (this behavior is by design).

Steps to reproduce the behavior:

The user deletes their default printer (the number of printers installed is irrelevant) for whatever reason. The user is warned this will change their default print device.

The Windows Spooler will arbitrarily choose a different print device as default for that user based on the list under HKCU\Software\Microsoft\Windows NT\CurrentVersion\Devices. Selection is prioritized: standard printers over virtual printers and local printers over remote connections.

The HKEY_CURRENT_USER\Software\Microsoft\Windows NT\CurrentVersion\Windows\UserSelectedDefault value will be changed from 1 to 0, indicating the user did not make an active decision to have this new printer as his default print device. Whenever a new print device is installed by the user, it will be automatically chosen as the default printer without asking the user if this is desired.

The HKEY_CURRENT_USER\Software\Microsoft\Windows NT\CurrentVersion\Windows\UserSelectedDefault value will be changed from 0 to 1, indicating the user actively installed this new printer, presumably wanting to have it as his default print device.

Prior to deleting a Print device that’s marked as the default printer, users should select a different default print device using the Devices and Printers Control Panel applet.

Additional Resources:

Users’ Default Printer can also be changed by other specific situations. Additional details about those situations can be found at the following links:

Location Aware Printing Walkthrough
http://technet.microsoft.com/en-us/library/ee424313(WS.10).aspx

Windows 7 / Windows Server 2008 R2: Location-Aware Printing
http://blogs.technet.com/b/askperf/archive/2009/10/10/windows-7-windows-server-2008-r2-location-aware-printing.aspx

Using Group Policy to Set Default Printers in Windows 7
http://technet.microsoft.com/en-us/edge/Video/ff710962

Remote Desktop Printer Redirection Settings
http://technet.microsoft.com/en-us/library/ee791784(WS.10).aspx

-Adam Richards

Two Minute Drill: DriverQuery.exe

Blake Morrison - MSFT — Fri, 21 Oct 2011 11:00:00 GMT

Hello AskPerf! Blake here to discuss an internal command line tool called DriverQuery. What exactly is DriverQuery? I’m glad you asked. In a nutshell, DriverQuery is a command line tool that displays a list of all installed device drivers and their properties. Let’s check out its options and some examples. When you type “DriverQuery /?” from a command prompt, the following appears:

Now let’s take a look at some DriverQuery examples:

Show all installed device drivers which includes Module Name, Display Name, Driver Type, and Link Date

C:\>Driverquery.exe

*To display addition columns (see below), add the “/V” switch

Module Name, Display Name, Description, Driver Type, Start Mode, State, Status, Accept Stop, Accept Pause, Paged Pool, Code(bytes, BSS(by, Link Date, Path, Init(bytes

Show all installed device drivers in a list view

C:\>Driverquery.exe /fo list

Do not list the column header

C:\>Driverquery.exe /nh

Find drivers that are not signed

C:\>Driverquery.exe /si | findstr FALSE

Find drivers that are currently Running

C:\>Driverquery.exe /v |findstr Running

For most of these commands, you may want to add the “>” command redirection option to output the results to a .txt file. For example:

C:\>Driverquery.exe /v > C:\results.txt

Additional Resources:

-Blake Morrison