UPDATE - 09/21/2011
I did an initial cursory review of the code and wherever it looks like the updating user interface that it does through:
SwingUtilities.invokeLater(new Runnable() { public void run() {
Major updates for the user interface take place in one place, which first executes the shell described above, and then requests the current visible panel for updates within this thread, so should it be within the EDT if I understand it correctly?
However, there may be strange places that I missed. I am currently working with some AspectJ code that I found here:
http://weblogs.java.net/blog/alexfromsun/archive/2006/02/debugging_swing.html
to see if it will highlight any odd places where he is not doing the right thing.
Also, though, any other thoughts?
Re: assumptions of transparency - how will this manifest? What am I looking for? Although I did a bit of work to improve the code, it is pretty much inherited from previous people, so I'm not as familiar with it as it can be useful :)
Re: inserting code fragments - I would love to, but without narrowing the problem, I can’t come up with a reasonable limited fragment for publication, I literally have no idea where the problem may be in the code, unfortunately.
Thanks for all the answers so far.
ORIGINAL QUESTION
We have an application hosted inside a third-party system. Our part is JPanel, which returns, the host application (Lagan CRM) then inserts this panel into its application.
In most cases, this works very well, but sometimes, and in only one implementation that we know about, the panel does not update correctly - it somehow stopped updating part of the panel.
In the screenshots below, our JPanel is located in the lower right, the upper left of it is the "INFO" button.
Here are some screenshots showing the problem:
In this example, the problem is visible around the Go to Unavailability and Dial areas. 
In this example, the problem is in one common area, but this is not the same measurement, indeed, we did not find any commonality regarding the region / size of the anomaly. 
In this example, I talked a bit with the user, and it looks like what happened before the user pressed the "GO UNAVAILABLE" button before the current call. Then they started a conversation with the caller, which means that the system should start showing “CONNECT” in the upper left corner, the phone number is lower, and it has a HANGUP button on the right. As you can see, it is updated only around it, there is a large block in the middle area that has not been updated at all, and still acts as if they are not ringing. Besides ugliness, this causes problems because there are two or three buttons that should replace “GO UNAVAILABLE”, which means that the functionality is not available. 
I just wanted to show some examples in order to see each time that they are different blocks, but the main problem is always the same.
Some key features:
Only on XP computers.
It is performed on only one client site from about 10-15 sites that use it, but occurs on all machines on this site.
I asked that the windows appear on top, but only they know that they sent me a screenshot, and it does not overlap a lot, of course, nothing remotely similar to these templates.
Java 1.5 is used on this site, and 100+ workstations upgraded to 1.6 are not impossible, but I will need to have some reasonable directions that it will help.
We have many other 1.5 sites without this problem.
We asked about what other software can run on machines, and there is very little honesty there, since they are contact center agent workstations and are tightly screwed down.
The panel will act on its own when the caller hangs up, but this means that the agent effectively loses this call because they cannot do anything with it. This implies that it is significantly blocked from updating, and is not constantly blocked.
The panel is implemented in SWING, there is nothing special about it.
Any hints, tips, tricks, suggestions on other issues, I can get answers to, or even better, solutions :) I will be very grateful.