Skip to main content

Overview

The Virtual Display Driver includes logging capabilities to help diagnose issues. This guide covers how to enable logging, interpret log files, and collect diagnostic information for troubleshooting.
Logging is disabled by default to minimize performance impact and prevent large log files. Only enable logging when actively troubleshooting issues.

Logging Configuration

Logging is controlled through the vdd_settings.xml configuration file.

Configuration File Location

The default location for the settings file is:
C:\VirtualDisplayDriver\vdd_settings.xml

Logging Settings

The driver supports two levels of logging:
Standard logging captures important events and errors without excessive detail.Configuration:
<logging>
  <SendLogsThroughPipe>true</SendLogsThroughPipe>
  <logging>true</logging>
  <debuglogging>false</debuglogging>
</logging>
When to use:
  • Investigating general issues
  • Monitoring driver behavior
  • Troubleshooting installation problems
Standard logging has minimal performance impact and is suitable for extended troubleshooting sessions.

Applying Configuration Changes

After editing vdd_settings.xml, you must restart the driver:
1

Save the configuration file

Make sure your changes to vdd_settings.xml are saved.
2

Restart the driver

Option 1: Using Device Manager
  1. Open Device Manager (Win + R, then type devmgmt.msc)
  2. Expand Display adapters
  3. Right-click Virtual Display Driver
  4. Click Disable device
  5. Right-click again and click Enable device
Option 2: Using PowerShell
# Run as Administrator
# From Community Scripts folder
.\toggle-VDD.ps1
3

Verify logging is enabled

Perform an action with the virtual display (e.g., change resolution) and check that log files are being created.

Log File Locations

Windows Event Tracing (ETW)

The driver uses Windows Event Tracing for Performance (WPP) for logging. Logs can be viewed using:
  1. Event Viewer:
    • Press Win + R, type eventvwr.msc, press Enter
    • Navigate to Windows Logs > System
    • Look for entries from “Virtual Display Driver” or “IddSampleDriver”
  2. Tracelog utility (part of Windows SDK):
    tracelog -start VDDTrace -guid #b254994f-46e6-4718-80a0-0a3aa50d6ce4 -f vdd.etl
    

Driver Log Files

When SendLogsThroughPipe is enabled, the driver may create log files in:
C:\VirtualDisplayDriver\logs\
The exact log file location may vary depending on driver version and configuration.

Reading and Interpreting Logs

Common Log Messages

Look for messages indicating driver startup:
  • Driver loaded successfully
  • Reading configuration from vdd_settings.xml
  • Monitor count: X
  • GPU selected: [GPU Name]
What to check:
  • Verify the correct GPU is selected
  • Confirm the expected number of monitors
  • Check that configuration file was read successfully
Messages related to display mode changes:
  • Resolution added: [width]x[height]@[refresh]Hz
  • Mode set: [width]x[height]@[refresh]Hz
  • Preferred mode: [resolution]
What to check:
  • Verify that your configured resolutions are being loaded
  • Check that refresh rates match your configuration
  • Look for errors in mode setting
Common error patterns to look for:
  • Failed to initialize
  • Configuration error
  • GPU not found
  • EDID parse error
  • Memory allocation failed
What to do:
  • Note the exact error message
  • Check the context (what was happening when the error occurred)
  • Verify your configuration file syntax
  • See Common Issues for solutions
When debug logging is enabled, you may see performance-related messages:
  • Frame rendered: [time]ms
  • Buffer allocated: [size]MB
  • Cursor update: [time]us
What to check:
  • High frame render times may indicate performance issues
  • Large buffer allocations may explain memory usage
  • Frequent cursor updates may impact performance

Log Analysis Tips

  • Timestamps: Pay attention to when errors occur relative to other events
  • Patterns: Look for repeating errors that might indicate a persistent issue
  • Context: Read messages before and after errors for additional context
  • Severity levels: Focus on ERROR and WARNING messages first

Using PowerShell for Diagnostics

The Community Scripts folder includes PowerShell scripts that can help with diagnostics.

Getting Display Information

# Get VDD display adapter number
.\get_disp_num.ps1

# This returns the numeric adapter ID by scanning for the MTT1337 identifier

Checking Driver Status

# Check if VDD is installed and enabled
Get-PnpDevice | Where-Object { $_.FriendlyName -like "*Virtual Display*" }

Querying Display Configuration

# Get current display configuration
Get-CimInstance -Namespace root\wmi -ClassName WmiMonitorBasicDisplayParams

# Get display modes
Get-CimInstance -Namespace root\wmi -ClassName WmiMonitorListedSupportedSourceModes
# VDD Diagnostic Information Script
# Run as Administrator

Write-Host "Virtual Display Driver Diagnostics" -ForegroundColor Cyan
Write-Host "=========================================" -ForegroundColor Cyan

# Check if VDD is installed
Write-Host "`nDriver Status:" -ForegroundColor Yellow
$vdd = Get-PnpDevice | Where-Object { $_.FriendlyName -like "*Virtual Display*" }
if ($vdd) {
    Write-Host "  Status: $($vdd.Status)"
    Write-Host "  Class: $($vdd.Class)"
    Write-Host "  Device ID: $($vdd.InstanceId)"
} else {
    Write-Host "  Virtual Display Driver not found" -ForegroundColor Red
}

# Check configuration file
Write-Host "`nConfiguration File:" -ForegroundColor Yellow
$configPath = "C:\VirtualDisplayDriver\vdd_settings.xml"
if (Test-Path $configPath) {
    $config = [xml](Get-Content $configPath)
    Write-Host "  Location: $configPath"
    Write-Host "  Monitor count: $($config.vdd_settings.monitors.count)"
    Write-Host "  GPU: $($config.vdd_settings.gpu.friendlyname)"
    Write-Host "  Logging enabled: $($config.vdd_settings.logging.logging)"
    Write-Host "  Debug logging: $($config.vdd_settings.logging.debuglogging)"
} else {
    Write-Host "  Configuration file not found at $configPath" -ForegroundColor Red
}

# Display adapter info
Write-Host "`nDisplay Adapters:" -ForegroundColor Yellow
Get-CimInstance -ClassName Win32_VideoController | ForEach-Object {
    Write-Host "  $($_.Name)"
    Write-Host "    Driver Version: $($_.DriverVersion)"
    Write-Host "    Status: $($_.Status)"
}

Write-Host "`nDiagnostics complete." -ForegroundColor Cyan

Collecting Diagnostic Information for Bug Reports

When reporting issues, include the following information:
1

System information

# Get Windows version
Get-ComputerInfo | Select-Object WindowsVersion, OSDisplayVersion

# Get GPU information
Get-CimInstance -ClassName Win32_VideoController | Select-Object Name, DriverVersion
2

VDD configuration

Include your vdd_settings.xml file (remove any sensitive information if present).
3

Enable logging and reproduce the issue

  1. Enable debug logging in vdd_settings.xml
  2. Restart the driver
  3. Reproduce the issue
  4. Collect the log files
4

Export Event Viewer logs

  1. Open Event Viewer
  2. Navigate to Windows Logs > System
  3. Right-click System and select Save All Events As…
  4. Save as vdd-system-logs.evtx
5

Screenshots and descriptions

  • Take screenshots of any error messages
  • Note the exact steps to reproduce the issue
  • Document when the issue started
  • List any recent system changes (driver updates, Windows updates, etc.)

Advanced Diagnostic Tools

IddCx Version Query

The driver includes a utility to query the IddCx framework version:
GetIddCx.exe
This tool is located in the driver installation folder and reports:
  • Installed IddCx version
  • Framework capabilities
  • Supported features

WPP Tracing

For advanced users, Windows Performance Toolkit can capture detailed traces:
  1. Install Windows Performance Toolkit (part of Windows SDK)
  2. Create a custom recording profile for display drivers
  3. Start recording:
    wpr -start GeneralProfile -start Video
    
  4. Reproduce the issue
  5. Stop recording:
    wpr -stop vdd-trace.etl
    
  6. Analyze with Windows Performance Analyzer (WPA)
This is an advanced technique primarily useful for driver developers and detailed performance analysis.

Disabling Logging After Troubleshooting

Once you’ve finished troubleshooting, remember to disable logging:
  1. Edit C:\VirtualDisplayDriver\vdd_settings.xml
  2. Set logging to false:
    <logging>
      <SendLogsThroughPipe>true</SendLogsThroughPipe>
      <logging>false</logging>
      <debuglogging>false</debuglogging>
    </logging>
    
  3. Restart the driver (disable/enable in Device Manager)
  4. Delete old log files to free up disk space
Create a backup copy of your configuration file with logging enabled so you can quickly re-enable it if issues recur.

Common Diagnostic Scenarios

Diagnostic steps:
  1. Enable standard logging
  2. Restart computer
  3. Check Event Viewer for driver initialization messages
  4. Look for errors in System log during boot
Common causes:
  • Configuration file syntax error
  • Missing dependencies (vcruntime140.dll)
  • GPU driver conflicts
  • Corrupted driver files
Diagnostic steps:
  1. Enable debug logging
  2. Monitor logs when disconnection occurs
  3. Check for power management settings
  4. Review GPU driver logs
What to look for:
  • Monitor disconnected messages
  • GPU driver errors
  • Power state changes
  • Memory allocation failures
Diagnostic steps:
  1. Enable debug logging
  2. Monitor frame render times in logs
  3. Check GPU usage in Task Manager
  4. Review cursor rendering performance
Common causes:
  • High refresh rates with insufficient GPU power
  • Debug logging enabled during normal use
  • Multiple high-resolution virtual displays
  • Software cursor fallback instead of hardware cursor

Next Steps

After collecting diagnostic information:

Common Issues

Check if your issue matches a known problem with a documented solution

GitHub Issues

Search existing issues or report a new bug with your diagnostic data

Configuration Reference

Review detailed configuration options that may help resolve your issue

Safe Mode Recovery

If your issue prevents normal Windows access, use Safe Mode recovery

Build docs developers (and LLMs) love