NatVis IncludeView and ExcludeView are ignored

[k3DW]

This works properly in Visual Studio, but it is not working in WinDbg.

This problem doesn't just manifest itself in custom types. This is an issue with standard library types that use IncludeView and ExcludeView, such as std::unordered_set. In the example below:

• bucket_count, load_factor, and max_load_factor should not be displayed, since STL.natvis annotated IncludeView="detailed"
• Similarly, there are 2 copies of allocator because one of them should not be here. It's annotated with ExcludeView="simple", and this subobject is called with <ExpandedItem>_List,view(simple)</ExpandedItem>, so it shouldn't be displayed.

0:000> dx set
set              : { size=0x3 } [Type: std::unordered_set<int,std::hash<int>,std::equal_to<int>,std::allocator<int> >]
    [<Raw View>]     [Type: std::unordered_set<int,std::hash<int>,std::equal_to<int>,std::allocator<int> >]
    [bucket_count]   : 0x8 [Type: unsigned __int64]
    [load_factor]    : 0.375000
    [max_load_factor] : 1.000000 [Type: float]
    [hash_function]  : hash [Type: std::_Compressed_pair<std::hash<int>,std::_Compressed_pair<std::equal_to<int>,float,1>,1>]
    [key_eq]         : equal_to [Type: std::_Compressed_pair<std::equal_to<int>,float,1>]
    [allocator]      : allocator [Type: std::_Compressed_pair<std::allocator<std::_List_node<int,void *> >,std::_List_val<std::_List_simple_types<int> >,1>]
    [allocator]      : allocator [Type: std::_Compressed_pair<std::allocator<std::_List_node<int,void *> >,std::_List_val<std::_List_simple_types<int> >,1>]
    [0x0]            : 1 [Type: int]
    [0x1]            : 2 [Type: int]
    [0x2]            : 3 [Type: int]

Here is a self-contained boiled-down example without any std lib includes.

struct S {};
int main()
{
    S s{};
}

<?xml version="1.0" encoding="utf-8"?>
<AutoVisualizer xmlns="http://schemas.microsoft.com/vstudio/debugger/natvis/2010">
    <Type Name="S">
        <DisplayString>S</DisplayString>
        <Expand>
            <Item Name="[only_in_detailed]" IncludeView="detailed">4</Item>
            <Item Name="[all_but_simple]" ExcludeView="simple">5</Item>
            <Item Name="[all_views]">6</Item>
        </Expand>
    </Type>
</AutoVisualizer>

Breaking in the main function, I would expect the s to show different items for different views, according to what I named them here. Instead, this is my output.

0:000> dx s
s                : S [Type: S]
    [<Raw View>]     [Type: S]
    [only_in_detailed] : 4
    [all_but_simple] : 5
    [all_views]      : 6
0:000> dx s,view(simple)
s,view(simple)   : S [Type: S]
    [<Raw View>]     [Type: S]
    [only_in_detailed] : 4
    [all_but_simple] : 5
    [all_views]      : 6
0:000> dx s,view(detailed)  
s,view(detailed) : S [Type: S]
    [<Raw View>]     [Type: S]
    [only_in_detailed] : 4
    [all_but_simple] : 5
    [all_views]      : 6

Similar behaviour also seems to happen when using IncludeView and ExcludeView on <Type> elements. As far as I can tell, the problem isn't limited to these attributes on <Item> elements.

Thanks

[wmessmer-msft]

This is a known issue -- views are presently "unsupported" in WinDbg though this is something we may eventually come back and revisit in part.

At the time adopted NatVis into WinDbg, it was pretty much a visualization only technology within Visual Studio (e.g.: you couldn't put expressions like foo[5] or foo.bar in watch/locals if the container notion or the name "bar" were provided by NatVis).

WinDbg made NatVis part of its data model. Anything which was added by NatVis was programmatically accessible on the object -- meaning that you could index the container or access keys in locals/watch... or pass that object to a JavaScript script and have it do similarly.

The original thought was that views would (eventually) not alter the SEMANTIC meaning of any object or its fields -- just be a "filter" which changes how they are DISPLAYED.

In that vein, today, we take all the views and "glom" them together into one object. We haven't gone back and done that "filtering" notion... to say nothing of the few visualizers which have different SEMANTICS depending on the ,view(...) which is applied...

[k3DW]

I see, thanks for the explanation. Regardless of whether the outcome changes, I appreciate knowing the reasoning and history.

[AlexK0]

I'm encountering the same issue and have been reviewing the documentation. From what I see, the debugger engine and debugger data model seem to be highly extensible.

@wmessmer-msft Could you please advise whether I am correct in understanding that this issue cannot be resolved by implementing a custom data model (registered via RegisterExtensionForTypeSignature) that extends exiting NatVis and handles IncludeView and ExcludeView attributes? It seems that the only way to address this would be to implement a separate data model that provides an alternative NatVis support from scratch, independent of the original NatVis implementation.

Thanks in advance!