Community Tip - Visit the PTCooler (the community lounge) to get to know your fellow community members and check out some of Dale's Friday Humor posts! X
Hi Creo 2.0 users,
Since we upgraded to Creo 2.0 we have the following problem. sometimes when we try to start Creo the application does not start. If we look into the task manager we then always see that one CPU core is running at 100% (a dual core says CPU load is 50% a quad core says 25% a.s.o.) used by xtop.exe. The RAM used by xtop.exe is always within a certain rance between 45.000K and 51.000K. This differs slightly from workstation to workstation and from case to case but it does not differ very much.
Sometimes we just need to start Creo a 2nd time (with the same configuration) and it starts well, sometimes it needs other tricks to get it running. What we have found so far is that sometimes if we just start with another License (e.g. CreopParametrick with AAX instead of plain CreoParametric) Creo starts successfully. Sometimes we need to tamper with the enviroment variable Pro_Lang. On some computers we need to set these variable to an invalid value in order to get Creo starting. On other computers our standard Pro_lang is set to german and they work works successfully.
If we start without any config.pro a complete plain and naked CREO it always works. We have tried to half/quarter a.s.o. our config.pro-file to identify if there is any line causing that problem but it was not reproducable at all. Sometimes everything works and sometimes it just does not work without any modification.
We have 13 licenses of CreoParametric/Essentials/AAX running on two different license servers in our company. Each of the licence servers is managing only a part of all our floating licenses. All client CAD-Workstations can use licenses from both licence servers. If the Creo start hangs, CREO always has reserved one licence for the session which does not start.
Using the CreoSystemMonitor (which is available since M060) does not give any information - The session is simply not yet recognized by the system monitor.
All our computers are running with Symantec Endpoint protection Version 12.1.1000.157 RU1 and we are not allowed to switch that off on the workstations.
We have still Windows XP64bit and plan to update to Win7-64bit this year. Our workstations are different HP workstations all with certified NVIDIA graphic cards. RAM is between 8GB and 32GB depending on the workstation. Processors are different intel Dual-, Quad and 8-Core.
After one year facing this problem its still there with the current M090 and I think that it might be a timing problem of some time critical processes during the start of the Creo application. I somehow cannot imagine any other cause of such non-reproducable error. Our Hotline cannot help us, because we cannot tell them a way how we could reproduce it.
Is there anyone out there who has similar experiences or ideas what the cause of that problem could be?
Solved! Go to Solution.
Hi Folks,
it seems that Creo M140 solved the problem or at least significantly reduced the no-start behaviour. Since we updated to M140 it has not happened again.
We also changed from two different Licence servers (running on different virtual servers) to only one server where all licenses are managed. This might also have been part of solving the problem.
Can you show us your config.pro so we can try to help you?
Sorry, I should have done that with my initial post.
Please find attached my current config.pro, taken from c:\Program Files\PTC\Creo 2.0\Common Files\M090\text\
The local workdirectory does not contain any other config.pro.
Do you create a new config.pro when new versions are released?
In a fast look i think there are some options not available now, so that can be the problem, try to start Creo
with the first 10 lines of config.pro, then add 10 more, then 10 more... i can't analise if the paths are all correct of even if they exist
When updating, we usually check if options are not available anymore and add new ones. In our case we did so when we updated from Wildfire 3 to Creo2.
As I wrote above, we did check the config.pro by splitting it in two halfs - then testing each half a.s.o. That should working as well as your proposal. For reproducable errors we should be even quicker than looking line by line or 10-lines by 10-lines.
The problem is: How do you recognize an error, when the error does not occur each time but only sporadically? You can wait until it happens once - then you modify your config. pro and afterwards it runs. You add the line(s) again to doublecheck and it runs too. So you are as wise or as thumb as before.
We are working with about 10 people with that config.pro and it happens "just" sporadically (once or twice a week at some workstations. At others luckily more seldom).
Furthermore - if I didn't even touch the config.pro. but just start Creo another way e.g. with the AAX-Licence option attached, the chance getting it running the next try is 90%. Or I just change in my batch script the Pro_Lang environmental variable from german to a non valid value or vice versa - again it works - until it hangs the next time.
Do you work in local domain or a simple lan connection?
We are working in a local windows domain (1000Mbit LAN).
My sugestion is to unplug your lan cable and start with no network acess to see if the error persist.
But without LAN there is no Licence and no company default configuration!
You can put the config.pro and the configuration local in your computer, do you use the option to map network drives? Sometimes the get disconnected for no reason and could be the cause of your problem
What do you mean with "Sometimes the get disconnected for no reason and could be the cause of your problem"? Have you experienced such behaviour before?
Shouldn't I see that in my filemanager/windowsexplorer, when mapped drives connections were interrrupted even, when it's for a short time?
Do you have any specific option in mint which could cause CREO to freeze, when at the startup for some milliseconds a mapped drive won't be available?
There are some network rules that come with server OS that are very restrict, i think you have a anti virus program running in your server and the clients in each workstation and that could be a issue too. I only say for you to unplugg the lan cable to see where the problem is, and yes i saw already some problems with mapped network drives and if that's the case check your network admin to see the rules in your server.
Hm, I have to think about how I'll get the license on the workstation then. As the flexlm is running on two network servers the only chance would be to borrow a license but as the behaviour changes when we use another license I am pretty sure that we cannor reproduce it then.
I forgot to tell that we have some laptops for traveling. We use the same configuration on them which means we just map the same network drives on the local loopback adress and borrow the licenses. We never experienced the same startup-freezing behaviour on one of our laptops.
Do you have any proposal on how we could get the license locally without borrowing?
Well, that is the problem when we have problems in Creo, we just can't try anything because we are stuck to that license and that is very bad. My sugestion is to contact your Creo reseller and borrow 1 license for some time to try and fix the problem, there isn't any "legal" option to do that
I really hope you fix the problem because hangs are annoying
Ok, thanks for sharing your ideas anyway. I think I'll try to "survive" until we switched to Win7. Otherwise PTC might say that XP is outdated and refuse to give a "trial license" for that purpose.
Hehe, that would be a very good idea!
Hi Folks,
it seems that we are to only one experiencing this matter???
I was hoping that perhaps someone else has similar issues and that we could compare our installation and configuration to look about common things which could cause that problem. It looks as if we has a quite "special" issue here, isn't it?
Hi Folks,
it seems that Creo M140 solved the problem or at least significantly reduced the no-start behaviour. Since we updated to M140 it has not happened again.
We also changed from two different Licence servers (running on different virtual servers) to only one server where all licenses are managed. This might also have been part of solving the problem.