There's a bug that got away from me in Windows 7's HD Audio class driver (hdaudio.sys.)

Before I explain the bug, a few caveats:

If you're using Vista, there's no problem.  This only affects Windows 7.

If you use the third-party audio driver, there's no problem.  This only affects the Microsoft HD Audio class driver (hdaudio.sys.)

If your recording devices (mic and line in) are independent (can capture from both at the same time) or muxed (can capture from one or the other but not from their sum) then you're fine; this only affects mixed capture (can capture from one, from the other, or from their sum, but not from both sides of the mix independently.)

If either of your recording devices doesn't support jack presence detection then you're fine; this only affects mixed capture where both sides of the mix support jack presence detection.

Here's the bug.

1. There are various ways to "reset" the system and bring the OS recording device state into synchronization with the hardware state
• reboot
• reset the HD Audio controller
• reinstall the audio driver
• restart the AudioEndpointBuilder service
• unplug all recording devices in the mix
  
2. The first state change (plug or unplug) after a reset works
3. The second and further state changes are not recognized by the OS until a reset.

Here's a sample state diagram assuming a mixed Mic and Line In (click to view full-size:)

Workarounds:

Install the third-party audio driver instead of the HD Audio class driver.

Use audio extension cables to fool the jack presence detection hardware into thinking something is always plugged in.

Regular expressions are a tool for matching generic text.  XPath queries are a tool for matching chunks of XML.  Both are search technologies.

When using search technologies it is occasionally quite useful to have a query that will never match anything - for SQL, this would be something like "SELECT 1 WHERE 1 = 0".

My candidates for minimal unsatisfiable regular expression:

/a\bc/
\b is a zero-width assertion that matches a boundary at the beginning or end of a word - specifically, it is true between a word-ish character (\w) and a non-wordish character (\W).  Since literal "a" and "c" are both wordish characters, this will never match.

Or, if you allow Perl extensions:

/(?!)/
This is a negative lookahead for an empty string.  Since the empty string always matches everywhere, this will never match.

My candidate for minimal unsatisfiable XPath query:

/parent::*
This matches everything at or under the parent of the root element.  Since, by definition, the root element has no parent, this will never match.