Rider can't provide user-friendly views of Unreal Engine data types when debugging

Hello Loong Nenu,

Unreal Engine uses pretty printers located in /Engine/Extras/LLDBDataFormatters/UE4DataFormatters.py to display Unreal Type in a more readable format similar to Natvis. You might need to add the path to the formatters into your .lldbinit file like this:

command script import "{path to Unreal Engine instance}/Engine/Extras/LLDBDataFormatters/UE4DataFormatters.py"

Please make sure that you are using an appropriate version of data formatters with your engine - some versions of UE from the Epic Games Launcher use incorrect UE4DataFormatters.py. Note that the engine from ue5-main and UE 5 Early Access should use the correct formatters.

Let me know if you encounter any issues.

Hi Kirill Filin

We are encountering a somewhat similar issue, in that data structures such as TArray and TMap, and classes such as FString are no longer displayed properly in the debugger. This has worked for us in the past, when we were using UE4 and Rider-for-UE, I'm not sure at what point it got broken, but we changed since to using a self-compiled UE5 (five, not four) and Rider (after the UE support got merged in to main Rider) instead of Rider-for-UE.

I have noted this particular support item we are talking about right now, as well as this page: https://www.jetbrains.com/help/rider/Unreal_Engine__Debugger.html

FWIW, in our Rider settings, we have "Build,Execution,Deployment -> Debugger -> Data views -> Enable NatVis renderers for LLDB enabled (it's enabled by default AFAIK anyway, but just mentioning it anyway).

I note too that the UE4DataFormatters.py (referred to by this ticket) is actually now called UEDataFormatters.py (note the 4 is gone), and the UE4.natvis (referred to in the above link) also no longer exists, it seems it might now be called Unreal.natvis (located in Engine\Extras\VisualStudioDebugging\).

So, in summary:

1. I don't know where .lldbinit (referred to by you in this support ticket) should be (there is no such file on my Windows system anywhere) located for Rider LLDB to use it

2. I don't know whether we should be loading that UEDataFormatters.py (if we even knew where to load it from for .lldbinit) at all, given that the link above talks about NatVis "instead" 

3. That UE4.natvis seems to now be Unreal.natvis, so I guess if Rider is looking for UE4.natvis file, it will fail

4. We're using a source-compiled UE5 (via Rider too, to be clear, as part of our project), not a globally installed binary release, in case that matters for Rider to find either the natvis or the python parser (RiderLink seems to have no trouble compiling and running with this FWIW)

Please advise, this is currently the biggest annoyance we have with Rider (and it wasn't always this way, it was fine in Rider-for-UE with UE4, as I mentioned). It seems like it could be something quite easy to fix or workaround, given that it seems like it might just be some files that have different names now.

Hi Bvl,

Unreal uses pretty printers (DataFormatters.py) on *nix systems, on Windows Unreal Engine and Rider use natvis files. If you are using Unreal Engine 5, Rider should look for and use Unreal.natvis for debugging. It seems like the issue might be caused by incorrect natvis file (in some cases natvis in development branch of UE can be incorrect) or Rider might have issues parsing a natvis file if you are customizing it in some way.

If possible, please:

• Open Settings | Build, Execution, Deployment | Debugger | Data Views | C/C++
• Set Diagnostics to Verbose (you can find the option close to "Enable NatVis renderers for LLDB"
• Reproduce the issue
• Open the Debug tool window (it might be already opened) and select the Debugger Output (LLDB) tab
• Copy the contents of the opened tab
• Send us the collected debugger output via the Upload Service (please mention the Upload ID in this thread) or via Help->Contact Support
• Set LLDB Diagnostics back to Disabled

Let me know if you have any questions or if you are not comfortable sharing this information for any reason

Hmm Kirill Filin, my "Enable NatVis renderers for LLDB" was enabled, and interestingly after I enabled the Diagnostics to Verbose (as you suggested,to try help track down the root cause), the problem went away, even after I restored the setting back to Disabled. Maybe something bad got cached somewhere and this somehow triggered it to be regenerated? Either way, now I can see FString, TArray, TMap again it seems, so thanks :) 

Tangential question:  Can I write a custom renderer for custom types (it looks easy enough from Unreal.natvis)? If so, where would I put such a file for Rider to recognise it? We have some often-used custom types that would be very handy to get a better view on in the LLDB debugger.

Bvl, you can use custom natvis files. There are two ways to include your custom natvis in your project:

• You can put them in the default VS natvis folder (<VS Installation Directory>\Common7\Packages\Debugger\Visualizers). Custom natvis will be applied across all projects using the MSBuild from this VS instance.
• You can put them in an arbitrary location and add them to your UE project (as long as you are opening your project as .sln instead of .uproject). To add the natvis file, please use the context menu of the solution explorer: Right click on the solution -> Add -> Add Existing Item. Please note that when you use "Generate project files", the included natvis file(s) might disappear from your project. In this case you will need to add them again.

I suggest trying the first approach first because you won't be forced to re-add natvis files the next time you need to regenerate your project files. 

Please let me know if you have any questions.

If anyone is still facing this issue in 2022.3.1 version {windows}, a clean uninstall and reinstall will do the trick

So it turns out another major cause of this problem is that some of the visualizers end with two greater-than characters, and that's breaking whatever parsing Rider and/or the debugger are doing. If you simply edit the Unreal.natvis and add a space to all of the types that end in "&gt;&gt" so that it's "&gt; &gt;" instead, then that fixes the visualizers.

For example, if you find the TArray entry using the TSizedInlineAllocator, which looks like this:

<Type Name="TArray&lt;wchar_t,TSizedInlineAllocator&lt;*,*,*&gt;&gt;">

And then add a space after the first &gt; so it looks like this:

<Type Name="TArray&lt;wchar_t,TSizedInlineAllocator&lt;*,*,*&gt; &gt;">

That will fix it. This isn't a problem with VisualStudio, so it's something specific to Rider that has some broken parsing. I'm guessing that it thinks it's the bitshift operator instead and that's breaking the type checking.

Hello Justin Grant,

Thank you for reporting this problem. I've filed a corresponding issue on our tracker. Please feel free to follow RIDER-88357 to monitor progress.