FEI DCOM issue

[Probeman]

Hi all,
Today I came into the lab and noticed that the Thermo Pathfinder was not showing the correct mag or stage positions on our FEI Quanta instrument. So of course I re-started Pathfinder because if someone had re-started the FEI software while the Thermo software was running, it will break the DCOM connection. But when the Thermo Pathfinder re-started I got the error "Failed to Connect" and then "Connection Not made".

Now you might ask, why am I posting this in the PictureSnapApp board?  Well, mostly because there is no FEI board on this forum, but also because when I start PictureSnapApp I also get the error "Permission Denied", so it seems the DCOM connection is now broken in general for all apps.

So I re-started the Quanta computer and software, but still no dice. I can ping the Quanta microscope computer at 192.168.0.1 from the Thermp?PSA computer fine, but both PictureSnapApp and Pathfinder refuse to connect to the FEI computer over the local 192.168.0.1 connection.

I should probably also re-start the Thermo/PSA computer but it's in the middle of a Monte Carlo calculation for a paper and I hate to interrupt it. Maybe tomorrow.

In the meantime, does anyone have any suggestions as to why the DCOM connection is suddenly broken, but the user logins for both computers are still the same?

[jrminter]

Have there been any recent updates to the system(s)?

It is a long shot, but you might want to verify that DCOM is enabled on both systems.

Check:
HKEY_LOCAL_MACHINE\Software\Microsoft\OLE\EnableDCOM

[UofO EPMA Lab]

Have there been any recent updates to the system(s)?

It is a long shot, but you might want to verify that DCOM is enabled on both systems.

Check:
HKEY_LOCAL_MACHINE\Software\Microsoft\OLE\EnableDCOM

Hi John,
John here.  I checked both computers and both their registry entries show a "Y" in that field.

Still trying various things but no luck so far.

[Probeman]

Have there been any recent updates to the system(s)?

It is a long shot, but you might want to verify that DCOM is enabled on both systems.

Check:
HKEY_LOCAL_MACHINE\Software\Microsoft\OLE\EnableDCOM

Hi John,
John here.  I checked both computers and both their registry entries show a "Y" in that field.

Still trying various things but no luck so far.

Well I've tried re-running the configure.cmd file for the DCOM configuration and that worked, but only after I set the user access control to Never Notify (I really don't like that so many apps require that this get turned off- that's not a good thing!).

Then I uninstalled and re-installed the FEI DCOM installer msi, but when I run the FEI test DCOM connection app it says connection failed.  As does the Thermo AutomationClient app and PictureSnapApp.  In fact the PictureSnapApp reports "Permission Denied" so that information tells me that the FEI microscope computer is refusing the connection for some reason.  I also tried from an admin account and adding the FEI test connection app through the firewall exceptions but still the DCOM connection isn't working.

But I can ping it and the user logins are the same on both computers, so I am at a loss...

It's so weird, it was all working fine last week.

[Probeman]

I heard from Thermo that another system of theirs stopped working all of a sudden last week also.

I'm suspecting a recent Microsoft update is killing DCOM for some reason.
john

[jrminter]

Is a system restore an option?

[Probeman]

Is a system restore an option?

Only as a last resort.

I did notice that I'm getting a new error when the computer is rebooted:

APPCRASH: SupportAssistAgent.exe

Could this have anything to do with these DCOM issues?
john

[jrminter]

This is a Dell PC, right? https://www.file.net/process/supportassistagent.exe.html suggests that supportassistagent.exe is part of Dell SupportAssistAgent software. This makes me think the MS patch has caused a lot of collateral damage.  https://www.computerworld.com/article/3290465/microsoft-windows/stung-by-a-festering-pile-of-bugs-on-patch-tuesday-ms-releases-27-more-patches.html suggests Microsoft patches have been pretty buggy lately... They claim corporate IT folks have been reluctant to install them... Sorry to be the bearer of bad news...

[Probeman]

This is a Dell PC, right? https://www.file.net/process/supportassistagent.exe.html suggests that supportassistagent.exe is part of Dell SupportAssistAgent software. This makes me think the MS patch has caused a lot of collateral damage.  https://www.computerworld.com/article/3290465/microsoft-windows/stung-by-a-festering-pile-of-bugs-on-patch-tuesday-ms-releases-27-more-patches.html suggests Microsoft patches have been pretty buggy lately... They claim corporate IT folks have been reluctant to install them... Sorry to be the bearer of bad news...

Hi John,
Yes, it is a Dell PC.  Yes, it's a Win 7 system.  Yes, I probably ran a Windows update last week.

Sigh...

I read the link and they did not mention DCOM specifically as being affected by these updates, but a number of TCP/IP issues were mentioned, so these recent updates could very well be the problem.  Let's hope Microsoft re-fixes these issues soon!
john

[jrminter]

I feel your pain. I had issues with Windows backup failing on my Win 7 box. I hadn't run a Windows backed up for a while (I had everything important backed up manually...) and had several (long) backup attempts fail (at the end, of course) with a very unhelpful error code... Even running checkdsk didn't help.  I tried several solutions from the web (such as backup from safe mode), but none worked properly. This was a long process...

On day 3, I unplugged all external drives but the main backup drive, deleted all the old backups on that drive, and ran a backup that passed. I have done two more since after updating programs. I just noticed that I have't created a system restore point since doing that, so I just started one...

Guess given MS's recent history, I think I will create a restore point before applying any major MS patch...

[Probeman]

I could never get the Windows Backup in Windows 7 to work properly so we're still using Norton Ghost which works great.

In the last 10 or 15 years, there's been half a dozen times when a hard drive failed in our lab (we do have 8 or so PCs that are always on), and we had to restore the drive from a backup.  30 minutes later and we're up and running again, so well worth it.

That reminds me that I should update Norton Ghost so we can start using it on the new Windows 10 system we have.

I wonder if it's worth contacting FEI to see if they've run into this Windows 7 DCOM issue recently?  Has anyone reading this had a similar problem with third party communications (usually EDS systems for reading the keV, mag, stage, etc.) with their FEI instruments, recently?

[Probeman]

In talking with Rich Westphall from Thermo support they found that on their Thermo system that stopped communicating with an FEI instrument at Penn State, they had to re-install the FEI xT software on the microscope computer (MPC), to get the DCOM talking again with the support computer (SPC).

I've located the FEI install disks and will attempt a re-install of the FEI software next, but in the meantime I discovered that one should not set the User Access Control to "Never Notify" on the Thermo/PictureSnapApp computer. Because if you do, then when you run the installer, the operating system doesn't pop up the prompt for the admin login, and the installer instead simply gives an error that the update needs to be run by an administrator.

This of course is on a user login that is *not* an administrative account.

[Probeman]

Today I came into the lab and noticed that the Thermo Pathfinder was not showing the correct mag or stage positions on our FEI Quanta instrument. So of course I re-started Pathfinder because if someone had re-started the FEI software while the Thermo software was running, it will break the DCOM connection. But when the Thermo Pathfinder re-started I got the error "Failed to Connect" and then "Connection Not made".

Now you might ask, why am I posting this in the PictureSnapApp board?  Well, mostly because there is no FEI board on this forum, but also because when I start PictureSnapApp I also get the error "Permission Denied", so it seems the DCOM connection is now broken in general for all apps.

So I re-started the Quanta computer and software, but still no dice. I can ping the Quanta microscope computer at 192.168.0.1 from the Thermp?PSA computer fine, but both PictureSnapApp and Pathfinder refuse to connect to the FEI computer over the local 192.168.0.1 connection.

I should probably also re-start the Thermo/PSA computer but it's in the middle of a Monte Carlo calculation for a paper and I hate to interrupt it. Maybe tomorrow.

In the meantime, does anyone have any suggestions as to why the DCOM connection is suddenly broken, but the user logins for both computers are still the same?

Just an update on the DCOM wars on our FEI Quanta Win 2000 computer...

We finally got the DCOM connection working again, but to be honest we really aren't exactly sure how it happened or what we did to fix the problem!  Yup, not very satisfying, but here's our best guess now that the smoke has cleared:

To begin with we think that the issue started when we temporarily connected the Quanta MPC to the Internet to allow the Norton Ghost software to renew it's subscription. Norton had been complaining that our license had expired so I thought, what's the harm in connecting an Internet cable to the PC?  I'll just change the IP address from static private to a dynamic address on the campus network, then restore the 192.168.0.1 static address afterwards. And we were able to renew the Ghost subscription and then I reset the connection back to it's original values, and was able to ping the computer through the 192.168.0.x subnet afterwards so all seemed fine network wise.

But apparently something was not happy and the DCOM would not connect even though we went through all the many steps provided to us by Thermo and FEI support. We then decided to try and get a duplicate hard disk we had made a few years ago, but for some other reason every time we tried to boot it up, it would get to the Windows 2000 logo and then blue screen.

Our instrument engineer tried everything he could think of but still no dice.  So then we called in the campus IT people to try and help us get the duplicate disk bootable, and so I demonstrated the DCOM problem on the original working disk, and lo and behold, the DCOM connections all worked perfectly!

The only thing we can think of is that somehow in the process of trying to re-boot the computer with a different disk and having to go into the ROM settings we somehow got the network card working properly again.  But who knows?

Jeez, what a pain, but PictureSnapApp and Thermo Pathfinder all seem happy now connecting to the Xt software on the Quanta MPC. I just hope this never happens to anyone else!

[Probeman]

This is somewhat related to the "DCOM hell" we recently went through on our FEI Quanta FEG instrument.  I'm posting it here in the hopes that it helps someone else avoid our pain and suffering.

Because this instrument is a "Mark I" model, the MPC (microscope PC) is still Win2K and there is no upgrade path for it.  However, it is not on the Internet, only the private network so no worries there.

Meanwhile the SPC (support PC) is on the Internet so students can upload/download their image files, and although I updated it from Win2K to WinXP some time ago, that apparently isn't enough any longer. Because recently the IT people said we had to update the FEI "Support" computer because they didn't want any WinXP computers on the campus network.

So we talked about Win7 vs. Win10 and because Win7 is not supposed to be supported by Microsoft after next year I decided to go with Win10.  I mean the only thing we were using it for was as a file server with a shared folder connection to the MPC over the private network. What could go wrong?

So the IT guy did a Win10 clean install and I re-installed a few apps but when we tried to create a shared folder it was weird. We could not connect to a shared folder on the new Win10 system from the Win2K system even though we could ping each of them from the other.

The IT guy called me back today to tell me he had figured it out. Apparently Win10 only support SMB v.2 which is the transport protocol used for sharing folders, while Win2K only supports SMB v.1. So they will never learn to share!    

But since Win7 supports both SMB v.1 and SMB v.2, we were able to create a shared data folder on the PictureSnapApp/Thermo Pathfinder computer that we could connect to from the MPC.

At least until after next year when the campus will start bugging us to upgrade from Win7 to Win10.   

Edit by John: just learned from our IT guy that XP also only supports SMB v.1, so apparently one cannot connect to a shared folder on Windows 10 from a WinXP computer either.

[jrminter]

Thanks for the update. I feel your pain. Does your university IT group have a variance process for these situations? That was one highlight of our corporate process. Our IT folks were sympathetic when they understood that there was no available upgrade for our microscope PC and that replacement of the microscope would have cost much more than $100K. They were willing to grant us a variance that was signed by senior IT management and gave us the best support they could. Like your situation, ours included buffer computers with all the service patches and anti-virus modules that were certified. I'd also check to see that you had the Enterprise version of Win-10 Pro on those systems so that your IT folks can verify the MS updates and schedule them at opportune times. I keep seeing new complaints about MS updates causing problems. We both know all too well the hours of lost productivity caused by botched updates.