I usually have one of two things happen:
User immediately closes dialog and then tells me my software is broken without any further explanation. A classic.
User reads it very carefully and gets confused because of the extra info, which seems to be what you suspected. When in reality the only important info is the first line. The weird ad-hoc LabVIEW error serialization within the source field ("<Err>" and family) just makes my life harder. The best solution I have found for this is to not use the built-in LabVIEW error dialogs for either display or error text sourcing. Their special handling is ok for LabVIEW programmers (but still not that great imo), and actively harmful for end-users.
I try very hard to make illegal states unrepresentable. This primarily means spending about around 2/3 or more of my time on validation and error handling. For example, if the user needs to enter in an IP address as suggested above I have several states that the interface goes through.
Have the "Ok", "Accept", "Connect" or whatever the button is to go to the next step greyed out and disabled. Have some text that says what to do. This text may be in a manual, but if it is it should also be relatively obvious from the UI perspective as well. This forces the user to enter in data in to the required field(s).
The user enters the data
Have an on value change event fire
Parse and validate the entered data
If valid, enable the button to continue
If invalid, keep the continue button disabled and also display what the user did wrong. This can be by a dialog (intrusive so I usually don't), or by blinking the invalid control and displaying a text indicator with the (user friendly!) error message. These usually have examples of correct input as well.
If your software can detect that the user has input invalid data then I highly recommend making invalid states unrepresentable in a form like this. Makes users happy because no scary error messages, and you happy because you don't have to worry about anything sneaking its way in to the rest system by accident (it happens!). So in essence by main solution to the error dialog issue is by treating error dialogs as bugs and a failure in proper input validation. This also includes if the user opens a file, but I do use dialogs to report those errors, but not LabVIEW error dialogs or errors in general.
