[IGN-4671]Random Component Name Error in Vision Client

Its not a good solution but it works ok for us.
Before I leave the client logged in to I click the icon to tell the error window to not popup on following errors, and then minimizing it. NOT closing!

1 Like

Just upgraded from 7.9.18 to 8.1.9 this week and this issue still exists. It did not do it on 7.9. No components have bindings in their names and it’s happening on multiple projects with completely different components. The only thing in common (other than Ignition) is I use CmRcViewer to remote into the clients. It would be nice to be able to disable the error windows. Going to be a pain if I have to remote in to minimize the error window every time a client reboots.

It seems to be something fundamental to Java Swing and Microsoft’s RDP implementation. It doesn’t happen with VNC or with any Linux technologies.

SCCM CmRcViewer and BeyondTrust/Bomgar both give this error for any of our Ignition 8 Vision clients. Odd that the error has persisted this long for one of the most widely used enterprise remote access tools…

Since this is the best thread for this issue, I’ve unresolved it and attached our internal ticket number.
We never got anywhere reproducing this each time we tried previously, but the specific callout of SCCM CmRcViewer that’s been repeated a few times might be a smoking gun.

For what it’s worth, I am currently still working on the system that @roger_larson originally posted this thread about. Despite any insistence that we would never have bound a component’s name property, over a year and half or so after this thread was posted I did indeed run across a handful of views where a newer developer had placed bindings on the name property of some components. They’ve been removed and I have not heard of anyone getting this error message since. I’m not saying that everyone else’s errors have the same cause, but it doesn’t hurt to double check even when you’re sure you would never have done such a thing. :upside_down_face:

1 Like

Definitely not the case for me.

Hi. I am also getting this error and it seems to only happen when we use the vision client over RDP. Yesterday evening I had around 250 null component name errors in 1 second, corresponding to when I was finishing work and closing down all my applications. When I use the system directly (no RDP), there are no errors.
I am currently working through the entire project to make sure that there are no bindings on the name properties but I am fairly sure that this is not the issue.

You will find that you have 250 components on that window. It’s not a binding on the name property, they should probably just remove the ability to bind to the name. I mostly live with this annoyance, but in a few cases I use an alternative platform to avoid it.

1 Like

Thanks Tim.

@PGriffith Any progress on this ticket? This came up this past week a bunch internally. (Our IT uses SCCM as well). We are running 8.1.13

21:05:41.719 [AWT-EventQueue-0] ERROR com.inductiveautomation.ignition.client.util.gui.ErrorUtil - Component name 'null' is invalid, it is either non-unique, reserved, or has an illegal character.

Nothing to report. It’s in the queue to be picked up, but no one’s sat down and tried to replicate yet.

In the meantime - is there anything about the settings of SCCM, these windows, etc that anyone can pinpoint as a cause? Does it happen at totally random times, or if the session is idle for a while, or anything like that?

No details yet, but I will try to get some more info. Its happening in one of our Asia facilities so its hard for me to get any hands on info first-hand.

The client logs seem to indicate the error pops up almost an error for every component on the window. As this window got 328 of the errors all at the same time. I can PM you some screenshots/resources if you think it will help.

I just ran a trial on a known offending project. I remoted into the computer using SCCM RC before launching the project. I launched the project and all was working fine. As soon as I disconnected SCCM RC, the error came up. 57 components on that screen had the “Component name null” error. As soon as I reconnect, then I got an additional 231 errors. Really annoying to have to remote reboot to get that error box off the screen. Disconnecting again added 5 errors. The number of components on the screen doesn’t seem to have anything to do with the number of errors.


I have a customer seeing this issue when running the remote management software PC-Duo.

Every time a remote session is started a null component name error is thrown for every component on the screen.

Can anyone experiencing this issue try putting the following code into a client startup script and reporting back?

from javax.swing import UIManager
UIManager.getLookAndFeelDefaults().put("Synth.doNotSetTextAA", True)

It’ll be a couple weeks before I get back there, but I’ll make a note to try this out.

I may be able to try this out sometime this week. Having a similar issue to others where there are some remote connected screens that have the error come up when it cannot be recreated on standard clients launched from a dev laptop. This supposedly did not happen on 7.9.12 but is occurring after the weekend upgrade to 8.1.17

1 Like

Turns out our situation may have been slightly different from some others, but here is how it went: They have an overhead TV above each press in one section of the facility. Each TV is connected over Ethernet to a PC (1:1) that is in a nearby closet. This PC is launching the vision client. I was never able to recreate the ‘null’ component reference issue on any clients other than these.

I put the lines of code mentioned above in the client startup script, had the customer restart the client, and the errors are no longer generated. For whatever its worth, they were using CmRcViewer to remote manage, and they restarted the Vision client and then also restarted Windows entirely. Each time no errors were generated, so I would say @PGriffith 's recommendation did the trick.

1 Like

The workaround I mentioned above will automatically applied by Ignition starting in 8.1.19. Anyone on any older 8.X version should be able to apply it with a client startup script with the same end result.