Use Work Queues or regular threads for Vista compatible WASAPI?

We have an application which has used WASAPI for years with both Exclusive and Shared Event driven mode.  In exclusive mode, we use the 3ms buffer.  If that is too small for our users' machines, we tell them to use Shared mode.  The rendering thread is just a std::thread which waits for the samples ready event and calls GetBuffer/ReleaseBuffer.  I have recently discovered that AvSetMmThreadCharacteristics() simply does not work in our particular situation.  I can't replicate the result in a smaller test app, so it must have something to do with using a .NET front end with a C++ COM dll back end or perhaps some other particular.  My testing methods were basically checking to see how easy it is to make it underrun, and it is incredibly easy unless by some other means I make the rendering thread's priority higher.  One method is sticking AvSetMmThreadCharacteristics() in the main thread.  I don't know why that works when calling it from the rendering thread does not.  In any case, while researching this I am seeing Microsoft telling us that using Work Queues is preferred over making our own threads.  A lot of the MF functions that make this more manageable are Windows 8 minimum, and we need to maintain backward compatibility with Vista.  I cannot find a WASAPI example which uses Work Queues which is Vista compatible.  Is there one?  If Vista compatibility is a requirement, then are Work Queues still preferred?  I managed to make a test app that uses Work Queues, but I cannot for the life of me figure out how to make the priority of my worker threads high enough to avoid underruns.  In my test app, creating my own thread and using AvSetMmThreadCharacteristics() made underruns nearly impossible to induce.  My inclination now is to just slog through and try to figure out why AvSetMmThreadCharacteristics() isn't working in our main application (where it works in our test app).  Any advice would be most appreciated.