This is a very common pattern and should absolutely not be patentable.
I can refute the root claim from this patent by demonstrating two prior arts: Microsoft's own Visual C++ debugger and the game file editor for my own open-source video game. I present both because they accomplish the claims of this patent in two different ways.
A computer-readable non-transitory storage medium configured with data and with instructions that when executed by at least one processor causes the processor(s) to perform a process for
This is filler text to say that it runs on a computer that saves its data & code on a hard drive.
utilizing an instance of an object type in a graphical programming environment
It should be obvious that the debugger has instances of object types in its GUI. In the game editor screenshot, you see the objects listed on the left in bold, with their properties indented. Properties in both examples can be other objects.
the instance having at least one field defined by the object type, each field of the instance having a name and capable of being assigned a value,
All fields in the debugger are defined by the object type. The "Name" and "Value" columns declare the name and value of a field (row) within an object. In the game editor, the name is to the left on a line with white background, and its value is to the right in gray text.
the process comprising the steps of receiving a selection that identifies the instance of the object type;
Clicking the object accomplishes this in both examples. By expanding an object, you select the instance of the object type whose fields you want to examine or edit.
automatically determining what fields are defined for the object type instance;
The debugger does this using metadata from the compiler ("program database", aka PDB files). Alternatively, the game editor does this using a mechanism in the source code itself. Each object has a standard interface to query for its defined fields. Details of the implementation can be found in the open-source code.
automatically generating an instance data population user interface in the graphical programming environment;
The debugger populates the "Locals" list view with variables automatically when a breakpoint is hit by the executing program. The game editor populates its list on program start. It takes a static root object, queries for its sub-objects, and adds those into the list. It repeats the process for each of the objects it just added until it reaches objects with no sub-objects.
and displaying at least the following in the user interface: the name of each field that is defined for the object type instance, and a currently assigned value for each field that currently has an assigned value.
This is again the "Name" and "Value" columns in the Visual C++ debugger, where each row is a field and an expandable block with a + next to it is an object type instance. In the game editor, the expandable blocks with a + on the left are object type instances, and the fields are either other object type instances or white lines. The white lines are again left-aligned bold text for the name, and right-aligned truncated gray text for the value.
Conclusion
There are, in fact, many more examples of visual debuggers other than Visual C++ that can counter these claims equally, but I chose Visual C++ because it was a Microsoft product, and presumably the Inventors would have been quite aware of it.
I believe all claims could all be easily invalidated by these two examples of prior art.