The following items are the IDs and titles of a subset of issues fixed between LabVIEW 2018 and LabVIEW 2018 SP1. If you have a CAR ID, you can search this list to validate that the issue has been fixed.
The following items are Bug Fixes in LabVIEW 2018 SP1.
Mouse cursor does not scale properly with DPI settings
On high resolution monitors, the cursor on seen on the Front Panel and Block Diagram will appear incredibly small. If you modify DPI settings, this will not impact the size of the mouse cursor as expected.
Class constants\controls appear grey on block diagram but VI's run arrow is unbroken
When you rename a class that uses another missing class in its private data control, then it is possible to corrupt some VIs such that a class constant or control is greyed out but leaves the run arrow in a working state. The greyed out control/constant is in a bad state and cannot be used -- it will report errors or cause crashes when the VI is run. The problem occurs on any VI that a) is in memory when you rename the outer class and b) contains controls or constants with ***non-default*** values.
Searching for text crashes LabVIEW
In some cases, searching for text within your application can cause LabVIEW to crash.
Error Ring will not accept %$ String modifiers
When using %$ modifiers in an Error Ring, they will be ignored and the Error Ring will not create input terminals to wire a String into them.
Separately compiled code takes longer to load with mismatched bitness
If you opt to separate your compiled code, this will link the code to the bitness used to compile the code. If you change between 32/64-bit afterwards, load times will be much greater than if the bitness matched.
LabVIEW crashes when using string control with the Python Node
If the function name string going into the Python Node is wired to a string control instead of a constant, LabVIEW crashes.
Configuring .NET Constructo Nodes or trying to view assemblies in memory may show an empty dialog box
In some cases, these will also show an error warning of potential corrupted memory. This will affect edit time behavior of .NET without corrupting memory in all cases.
Undefined data types do not resolve with Malleable VIs
Data types that are defined by functions in the code start as an undefined type. The most common example of this is an uninitialized Shift Register. Malleable VIs accept any inputs. Mixing these two ideas caused behavior that break some Polymorphic VIs.