This includes:

• ID3D11Device2
• ID3D11DeviceContext2
• HLSL Shader Linking
• Tiled resources

Basically anything listed here:

http://msdn.microsoft.com/en-us/library/windows/desktop/dn312084(v=vs.85).aspx

Now that doesn’t mean 11.1 and below doesn’t work. In fact we fixed a number of bugs in our second update to VS 2012, and as long as you use 11.1 interfaces (or below) everything else should work on Windows 8.1

Why doesn’t it work?

If you really care to know, I’m going to go into some detail on how we actually do graphics diagnostics. This will explain why 11.2 doesn’t work in VS 2012 and what we plan to do to address this in the future.

Capturing

When you hit print screen during graphics diagnostics, we “capture” a frame of your app running. You can see all the stuff your frame did in the event list here:

So how do we “capture” this list of events?

Detours

For VS 2012 (and previous incarnations of WinPIX), we use something called detours. Detours essentially rewrites the beginning of a function so that it jmps to somewhere else. Here’s the disassembly for D3D11CreateDevice:

This is what D3D11CreateDevice looks like before it is detoured.

After detouring, this assembly changes to this (notice the new jmp):

This means calls to D3D11CreateDevice go to another create device function.

However, this other function still needs to call the original, so detours also creates a “trampoline” function to allow us to call the original:

Here’s an example of a new detoured CreateDevice:

HRESULT CHookedD3D11Top::D3D11CreateDevice( D3D11CREATEDEVICE_TYPED_PARAMS )

{

    if ( D3D11CreateDevice_Trampoline == NULL )

        return E_NOINTERFACE;

    m_pHookMgr->LogInputParams( D3D11CREATEDEVICE_PARAMS );

    HRESULT hr = D3D11CreateDevice_Trampoline( D3D11CREATEDEVICE_PARAMS );

    m_pHookMgr->LogOutputParams( D3D11CREATEDEVICE_PARAMS, hr );

    return hr;

}

Essentially we:

• Intercept the call
• Log the input parameters
• Make the original call
• Log the output parameters

This allows us to log/(and more importantly) recreate all the things your app did while running.

Sounds simple, so why not just add logging for the new 11.2 apis?

Hooked objects

It’s actually a bit more complicated than that. In the example above, the ID3D11Device returned from the function is likely going to be used later, to say create textures.

The workflow here is:

1. Game calls D3D11CreateDevice
2. We intercept in our detoured HookedD3D11CreateDevice
3. We call into the RealD3D11CreateDevice
4. It returns a real device object
5. Game calls the ID3D11Device::CreateTexture
6. We don’t capture this. Well because CreateTexture is called on something we aren’t detouring.

You can’t detour a virtual function (not with the detours api anyway, more on this later) so we need to do more than just detour the straight create functions. We also need to wrap objects as they are returned.

This gives us something like so:

Now we can log our HookedDevice::CreateTexture. It’s code would look something like so:

HRESULT CHookedD3D11Device::CreateTexture2D( D3D11CREATEDTEXTURE2D_TYPED_PARAMS )

 {

     m_pHookMgr->LogInputParams( D3D11CREATEDTEXTURE2D_PARAMS );

     HRESULT hr = m_pRealDevice( D3D11CREATEDTEXTURE2D_PARAMS );

     m_pHookMgr->LogOutputParams( D3D11CREATEDTEXTURE2D_PARAMS, hr );

     if (hr == S_OK)

         *ppTexture = m_pHookMgr->WrapObject(*ppTexture);

     return hr;

 }

This is the general pattern we follow throughout our hooking.

Things get messy in some scenarios however.

QueryInterface

QueryInterface is a special function. This is the way a COM object is queried for new types.

HRESULT QueryInterface(
  [in]   REFIID riid,
  [out]  void **ppvObject
);

In our example, our HookedDevice has its own implementation of QueryInterface. What happens when we QI for some interface we don’t know about (like say ID3D11Device2)?

There are really two things we can do (well that I’ve thought of)

Off the farm

We could just return the original m_pRealDevice object. This means if you QI for ID3D11Device2, and then start calling functions on it, we won’t hook them and capture won’t succeed. This means your app will probably run under the graphics debugger, but we’ll just miss calls.

Imagine this workflow:

1. Create device
2. QI for ID3D11Device2
3. GetImmediateContext2
4. Call draw calls on ID3D11DeviceContext2

In step 2, the QI for ID3D11Device2 is not understood by VS 2012 (well because ID3D11Device2 didn't exist yet). So it returns the original object. In step 3, the immediate context returned is not our hooked immediate context, and in step 4, the draw calls are not hooked. This means the QI for ID3D11Device2 goes “off the farm” and we can’t see our sheep anymore.

This scenario actually came up during development of VS 2012. It seems D2D actually queries a device for internal only interfaces that it knows about. This means if you use D2D in your app, you wouldn’t have been able to capture with VS 2012. Pretty crummy.

VTable patching

This prompted us to actually not return hooked objects, but instead to return the original m_pRealDevice (from D3D11CreateDevice) and patch its vtable to point to our Hooked API calls. This is another form of detouring that allows the QI to go “off the farm” but come back onto the farm whenever a call is made to a known API.

It works something like so:

The real device starts out something like so:

Then we create a hooked device that looks like this:

Then we rewire the Original Device to point to the VTable of the HookedDevice and the hooked entries to call into the original as necessary:

This allows us to always return the “original” object, but have its functions still detoured, and when subsequent QI’s happen for unknown interfaces, we can patch just those vtables for the IUnknown vtable.

Additional difficulties

This seems to fix the capture with 11.2 problem. As long as the original vtable is patched, any new interfaces would at least work (if not capture). However there’s a problem here.

DirectX itself is patching vtables. The device context is patched at the vtable by DirectX to swap out feature levels. This breaks our vtable patching. So we can only returned hooked objects for device contexts.

Supporting 11.2 = VS 2013

Given all of this background, you may be able to see how much work it is to actually hook DirectX. Months of patching vtables here, making sure parameters are copied correctly, etc. Not to mention responding to changes as they come up. DirectX changed some of the 11.1 APIs 5 times during the release of VS 2012.

The ideal alternative would be for DirectX itself to support hooking DirectX APIs. This way DirectX could keep the hooks up to date as they made changes to their APIs and handle any private interfaces that might come up.

For VS 2013, this is what we are doing. From now on, DirectX detouring will be handled internally by DirectX itself. This eliminates the need for us to keep updating our hooking every time DirectX adds new APIs.

So given all of that, we’re not porting this change to VS 2012 for a couple of reasons:

1. It would take up months of development time we could be spending on new features.
2. The new version will be free (for store apps, and somewhat useable for desktop apps)

I’ll leave the details of the new DirectX hooking as a topic for a future post

Suppose I have an image I'm about to draw to the screen. Let's say this image has the RGBA color of (1.0, 0.5, 0.0, 0.5) which looks like so:

And suppose I want to blend this with the background (0.0, 0.0, 1.0, 1.0) which might be something like the following:

How do I blend them together?

D3D has this nice option in the output merger stage, that allows you to blend what your draw did with whatever was previously in your render target. You do this by calling OMSetBlendState which takes an ID3D11BlendState object.

You set your blend state object with a series of flags that looks like so:

    D3D11_BLEND_DESC bs;
    ZeroMemory(&bs, sizeof(bs));
    for (int i=0; i<8; i++)
    {
        bs.RenderTarget[i].BlendEnable = TRUE;
        bs.RenderTarget[i].BlendOp = D3D11_BLEND_OP_ADD;
        bs.RenderTarget[i].BlendOpAlpha = D3D11_BLEND_OP_ADD;
        bs.RenderTarget[i].RenderTargetWriteMask = D3D11_COLOR_WRITE_ENABLE_ALL;
        bs.RenderTarget[i].SrcBlend = D3D11_BLEND_ONE;
        bs.RenderTarget[i].DestBlend = D3D11_BLEND_ZERO;
        bs.RenderTarget[i].SrcBlendAlpha = D3D11_BLEND_ONE;
        bs.RenderTarget[i].DestBlendAlpha = D3D11_BLEND_ONE;

    }

What do all those flags mean?

This is where I feel like the documentation is lacking. There are 2 enums you have to deal with here:

• D3D11_BLEND_OP
• D3D11_BLEND_MODE

Let’s talk about each one separately.

BLEND_OP

The BLEND_OP is a little bit easier to understand. Basically when you are blending, you are combining the original color (the one already in the render target) with a new color (the one you are outputting on your current draw). The BLEND_OP specifies how you combine these colors after applying the blend mode. It’s one of:

• ADD
• SUBTRACT output from original
• SUBTRACT original from output
• MIN
• MAX

BLEND_MODE

BLEND_MODE is a little more complicated. This is where the confusion set in for me. BLEND_MODE has a bunch of different values, like SRC_COLOR, SRC_ALPHA etc. What these mean is where to get our multiplier from. The general formula for the blend is like so:

FinalColor = (SourceColor * Source BlendFactor) Blend Op (DestinationColor * Destination BlendFactor)

BLEND_MODE just lets us decide how to compute the BlendFactor in that equation above.

This makes a big matrix of possibilities. So what might the results be? I created an example table using just the R value from each of my colors:

Now this table is certainly not the limit of what the matrix might be, this table is simply specifying OP_ADD and using the same blend mode for both the source and destination, In a blend desc, this would be set like so:

    D3D11_BLEND_DESC bs;
    ZeroMemory(&bs, sizeof(bs));
    for (int i=0; i<8; i++)
    {
        bs.RenderTarget[i].BlendEnable = TRUE;
        bs.RenderTarget[i].BlendOp = D3D11_BLEND_OP_ADD;
        bs.RenderTarget[i].BlendOpAlpha = D3D11_BLEND_OP_ADD;
        bs.RenderTarget[i].RenderTargetWriteMask = D3D11_COLOR_WRITE_ENABLE_ALL;
        bs.RenderTarget[i].SrcBlend = D3D11_BLEND_ONE;
        bs.RenderTarget[i].DestBlend = D3D11_BLEND_ONE;
        bs.RenderTarget[i].SrcBlendAlpha = D3D11_BLEND_ONE;
        bs.RenderTarget[i].DestBlendAlpha = D3D11_BLEND_ONE;

    }

This example is probably a silly idea, as you want to combine the destination and source in different ways. This blend mode above is just adding up all the colors together, more than likely getting something close to white each time.

The default (meaning no blending) would effectively be like so:

    D3D11_BLEND_DESC bs;
    ZeroMemory(&bs, sizeof(bs));
    for (int i=0; i<8; i++)
    {
        bs.RenderTarget[i].BlendEnable = TRUE;
        bs.RenderTarget[i].BlendOp = D3D11_BLEND_OP_ADD;
        bs.RenderTarget[i].BlendOpAlpha = D3D11_BLEND_OP_ADD;
        bs.RenderTarget[i].RenderTargetWriteMask = D3D11_COLOR_WRITE_ENABLE_ALL;
        bs.RenderTarget[i].SrcBlend = D3D11_BLEND_ONE;
        bs.RenderTarget[i].DestBlend = D3D11_BLEND_ZERO;
        bs.RenderTarget[i].SrcBlendAlpha = D3D11_BLEND_ONE;
        bs.RenderTarget[i].DestBlendAlpha = D3D11_BLEND_ZERO;

    }

Although this is just the same as setting BlendEnable to false. Most of the time what people want to do is actually blend using the alpha component. This produces a nice effect where you can sort of see the stuff behind what you are drawing. A common way to do that would be to pick the following:

    D3D11_BLEND_DESC bs;
    ZeroMemory(&bs, sizeof(bs));
    for (int i=0; i<8; i++)
    {
        bs.RenderTarget[i].BlendEnable = TRUE;
        bs.RenderTarget[i].BlendOp = D3D11_BLEND_OP_ADD;
        bs.RenderTarget[i].BlendOpAlpha = D3D11_BLEND_OP_MAX;
        bs.RenderTarget[i].RenderTargetWriteMask = D3D11_COLOR_WRITE_ENABLE_ALL;
        bs.RenderTarget[i].SrcBlend = D3D11_BLEND_SRC_ALPHA;
        bs.RenderTarget[i].DestBlend = D3D11_BLEND_INV_SRC_ALPHA;
        bs.RenderTarget[i].SrcBlendAlpha = D3D11_BLEND_ONE;
        bs.RenderTarget[i].DestBlendAlpha = D3D11_BLEND_ONE;

    }

What this does is makes the src alpha component more important in the final output, and destination color less important (the inverse applied). For our image above this would be:

Final Color = (Source Color * Source Alpha) + (Destination Color * Inverse Source Alpha)

Final ColorR = (1.0 * 0.5) + (0.0 * (1.0 – 0.5))

Final ColorG = (0.5 * 0.5) + (0.0 * (1.0 – 0.5))

Final ColorB = (0.0 * 0.5) + (1.0 * (1.0 – 0.5))

Final Color = (0.5, 0.25, 0.5)

This ends up looking like so when we overlay:

http://msdn.microsoft.com/en-us/hh965632.aspx

Hi, welcome back. If you look at my older posts, you may notice that I don’t publish very much. Mostly because I’m lazy and I hated the tools inside of blogs.msdn for writing posts.

Well they’ve made it much easier now -- and I have a new job. Basically creating this:

Most people call it Visual Studio PIX. We’re calling it the Visual Studio Graphics Debugger.

I’ve always wanted to write video games. Working on this tool has finally pushed me into this realm and I hope to share everything that I’ve learned. That’s my new goal for this blog. I’d like to teach myself (and anybody that reads this blog) how to write DirectX based C++ games.

I know it’s been done before, but maybe I can explain something nobody is answering. Or at least teach one person about DirectX = me.

But if you have questions about the screenshot above, feel free to ping me (There are others blogging about it too)

Yesterday a colleague and I were both logged onto the same machine, both using Visual Studio as two different users. Since I work at Microsoft, I naturally needed to change Visual Studio. So how to do that without having my co-worker log off (because he had the same dlls loaded I needed to change)?

Registry hives

VSIP (well actually Visual Studio) has this nifty idea where you can load devenv using a different root key in the registry. The intent here is that when you are developing a Visual Studio package you can build the package in one instance of Visual Studio and run in another. This means the package is not loaded in the same environment you are building in. Very handy when your package causes Visual Studio to crash. How would you debug it if you can't even start Visual Studio?

 So most of the time (at least in my past) people use the Exp hive. If you look in your registry, you'll have a root install of HKLM\Software\Microsoft\VisualStudio\8.0. The Exp hive lives at HKLM\Software\Microsoft\VisualStudio\8.0Exp. If you install your package in just the Exp hive, you can run the Exp version and debug with the normal.

Package redirect

So how did I use this exp hive to my advantage?

Packages are loaded dynamically as devenv needs them (usually when a command or window from the package is called). The location for these packages is stored in the registry underneath the root location for Visual Studio (i.e. HKLM\Software\Microsoft\VisualStudio\8.0\Packages\{package guid}).

For example, the debugger package (which is what I wanted to change) is loaded from here:

Since my colleague was using the 9.0 hive, I could just change the package load location for my Exp hive and have my version of devenv load a different dll!

Something like so:

SxS (or side by side) was a solution Microsoft developed for people distributing the C runtime with their application.

I won't comment on whether or not this was the right solution to the problem, but I'll talk about what I do to resolve it.

Is it SxS?

Anytime an application doesn't load a dll or refuses to start for some reason, I suspect SxS. Usually you'll get something like:

The application has attempted to load the runtime library incorrectly.  Contact support for more information

This application has failed to start because the application configuration is incorrect

At this point, I do one of the following to make sure it is a side by side issue:

• Open the event log in (XP/Vista) and look at the Application or System list. There should be a SxS error in there somewhere
• Open the offending dll or exe using depends.exe (usually installed with Visual Studio under Common7\Tools\Bin). It will tell you if there is a SxS issue.

Do I have that CRT installed?

So one reason you might be having sxs problems is you don't even have the appropriate run time dlls installed. Usually this isn't the case, but I say it here first just to make sure you check.

To check if you do:

• Open the event from the event viewer that identifies what dll it is trying to load. Vista shows something like so:

Component identity found in manifest does not match the identity of the component requested. Reference is Microsoft.VC80.ATL blah blah blah

• Go to your Windows\WinSxS directory and see if you have a directory with a name containing the reference. Vista could have multiple.

If you find a directory containing the name of the runtime, then some version of that runtime is installed. You probably need to redirect.

Redirecting - Fixing the problem

Obligatory warning: Mucking with system files can screw stuff up later on. Not that I've had problems after doing any of these fixes, but people say it's unsupported. I wouldn't recommend this as a "fix" but rather a workaround on your development machine.

Anyway, here's what I do depending upon the platform:

XP/2003 Server

• Go to the event log. Find the error that names the dll you are having trouble with (there might be 3 or more errors for your one side by side load)
• Go to the Windows\WinSxS\Policies\<goofy directory containing your CRT dll name>
• Edit the .policy file with the largest number.
• Change the binding redirect to be like so:

<bindingRedirect oldVersion="9.0.0.0-9.0.65535.65535" newVersion="9.0.xxxxxx.xxxxx"/> 

• The critical part here is that the the newVersion value matches the policy file's main number. Here's one on my machine:

 

name="policy.9.0.Microsoft.VC90.DebugCRT" version="9.0.20223.44800"

Make sure the number at the top of the file matches the newVersion you type in.

Vista

• Go to the event log. Find the error that names the dll you are having trouble with (there might be 3 or more errors for your one side by side load)
• Go to the Windows\WinSxS\Manifests
• Find the newest manifest file with the name like so

x86_policy.8.0.microsoft.vc80.atl_1fc8b3b9a1e18e3b_8.0.50727.762_none_8e053e8c6967ba9d.manifest

The important parts being x86_policy and microsoft.vc80.atl - this name matches the runtime you are trying to redirect. The rest of the name doesn't really matter, although it should be the newest file and probably the highest version x86_policy file in that directory for your runtime.

My friend John discusses another alternative (at least on Vista) to find the appropriate file: sxstrace

• Edit this file and change the binding redirect to be like so:

<bindingRedirect oldVersion="8.0.0.0-8.0.65535.65535" newVersion="8.0.xxxxxx.xxxxx"/> 

• The critical part here is that the the newVersion value matches the policy file's main number. Here's one on my machine:

 

name="policy.8.0.Microsoft.VC80.ATL" version="8.0.50727.44800"

Make sure the number at the top of the file matches the newVersion you type in.

• Here's another caveat for vista = saving the file. You probably aren't the owner of this file. You need to remove whoever is the owner, and make yourself owner of this file before you can save it. I'll leave that step up to the user for brevity's sake.

After changing the appropriate policy file, your app should start to work. If it doesn't, hey you might have a dependency on another part of the CRT. Check the event log again :)

Update: How to tell when this isn't going to work

So I finally ran into a case when this workaround failed. When the CRT is actually different and your application is using the wrong CRT! Duh.

You'll get something like:

---------------------------
devenv.exe - Entry Point Not Found
---------------------------
The procedure entry point ?replace@?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@QAEAAV12@V?$_String_const_iterator@DU?$char_traits@D@std@@V?$allocator@D@2@@2@0ABV12@@Z could not be located in the dynamic link library MSVCP80.dll.
---------------------------
OK  
---------------------------

In this case you actually need to go through the correct channels - like trying to find this version of the CRT and installing it. Should be installed under:

Program Files\Microsoft Visual Studio 8\SDK\v2.0\BootStrapper\Packages\vcredist_x86

You might also try a manifest for the appropriate dlls. Here's a blog entry about it.

I had 3 separate "support" calls this weekend:

1. My wife informed me that Win32 was not working on our laptop.
2. My in-laws told me that they couldn't see themselves when talking to us through video conferencing (and hence we couldn't see them either)
3. Our laptop was consistently blue-screening (separate issue from the first) during video conferencing.

All 3 of these problems would not be diagnosable by say my wife. In fact one of them was only fixable because of the specific knowledge I have from working here.

PC's still aren't ready or usable by home consumers. At least not without a lot of hand holding and support. How come we haven't fixed this yet? Why do PCs have to be so techie? Okay I know why, but the reasons/excuses seem shortsighted to me.

What if we had an OS where all drivers were controlled/written by the vendor. What if the whole OS allowed but a single app to run at a time? And what if you had to control it with say, a game controller, instead of a keyboard and a mouse?

I think for Christmas next year I'm buying everybody an X-box with live and a camera.

Now if only X-box live would come with a browser.

The code was something like so:

The problem I was trying to demonstrate, while stepping through some code, was a race condition occurring on a collection (one of our new features is supposed to help point this out). However, whenever I stepped, the other threads kept hitting the breakpoint, moving my ip indicator back to the breakpoint, and generally screwing stuff up.

Here's a screenshot of it in action (notice our new other thread indicators)

Yeah this is a pain. I want to just step in this first thread. I guess I could wait until the right thread gets to the breakpoint, then freeze everybody else. This doesn't seem to work though (mostly because of the internal state of the other threads)

But wait, there is a way to step in just this thread!  

Here's how:

1. Right click on the breakpoint and select "Filter" from the list of options
2. When the filter dialog appears, type in a filter condition. I used ThreadName=<my thread name>
3. Click OK

Now when the breakpoint gets hit, only this thread will be in stepping mode. (Something else I learned, threads are in one of 3 states - stepping, running, or suspended)

So as you step, the IP indicator won't jump around.

Of course this then made me want more, but I'll leave that for another post.

That sounds like an admission of guilt. 

I suppose in some ways I do feel guilty working here. I work for the man now. No longer am I one of the free spirited plebes of the software world. I am now the property of Mr. Bill.

I've been here for 8 months as part of the Visual Studio Diagnostics team - specifically working in the Visual Studio debugger. I'm hoping that this blog will let me discuss some of the interesting things I've found (or am trying to do) with the debugger.