cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
Showing results for 
Search instead for 
Did you mean: 

Community Tip - Did you get an answer that solved your problem? Please mark it as an Accepted Solution so others with the same problem can find the answer easily. X

Creo will not start for publishing

BenLoosli
23-Emerald II

Creo will not start for publishing

I have upgraded to CreoView 3.0m032 and now Creo will not launch to publish any files.

I have cleared all of the cache files.

I get a "did not find available worker" error message.

Any suggestions as to what I missed?

 

22 REPLIES 22
RandyJones
19-Tanzanite
(To:BenLoosli)


@BenLoosli wrote:

I have upgraded to CreoView 3.0m032 and now Creo will not launch to publish any files.

I have cleared all of the cache files.

I get a "did not find available worker" error message.

Any suggestions as to what I missed?

 


Perhaps the exec_file path to the dll in the protk.dat? This will almost always change when updating Creo View Adapters.

dharlan-2
4-Participant
(To:BenLoosli)

I'm assuming you checked the compatibility matrix to make sure that adapter works with your version of WC?

Did you rebuild the recipe and batch files?

BenLoosli
23-Emerald II
(To:dharlan-2)

Yes, the build install was requested by PTC and I verified it both with the tech and by the document matrix.

Recipe and batch files have been rebuild by the adapter_config program.

 

Creo runs on that machine when started standalone.

Creo will start when launched from proepublish.bat.

Creo does not start when launched from proeworker.bat.

BenLoosli
23-Emerald II
(To:BenLoosli)

Continuation of same problem but different versions!

I have upgraded to Windchill 11.0 m030 and installed CreoView Adapters 4.1 F000.

The WorkerDaemon starts on the publishing machine at startup from the GS Worker service.

The proeworker will not start automatically. I have to log into the publishing machine and start proeworker.bat every day. Once started publishing runs fine for that day.

 

Has anyone seen this issue with the system not fully starting automatically? When I had the issue earlier, PTC tech support could not find a solution so I closed the call hoping WC 11 and the new adapter would allow the startup to work.

 

RandyJones
19-Tanzanite
(To:BenLoosli)


@BenLoosli wrote:

Continuation of same problem but different versions!

I have upgraded to Windchill 11.0 m030 and installed CreoView Adapters 4.1 F000.

The WorkerDaemon starts on the publishing machine at startup from the GS Worker service.

The proeworker will not start automatically. I have to log into the publishing machine and start proeworker.bat every day. Once started publishing runs fine for that day.

 

Has anyone seen this issue with the system not fully starting automatically? When I had the issue earlier, PTC tech support could not find a solution so I closed the call hoping WC 11 and the new adapter would allow the startup to work.

 


Basically all proeworker.bat does is to start a workermonitor.exe process. The workermonitor.exe process is what Windchill uses to start/end the Creo Parametric session. The workermonitor.exe process then "lives" forever unless you kill it the the Worker Agent Administration dialog or from the cadworker machine's task manager or you restart Windchill. So this is why starting it manually would allow publishing to work.

Your issue sounds like one of two possibilities:

  • Your cadworker Windows firewall is preventing Windchill from running proeworker.bat
    • I have had this happen
    • Turn off the Windows firewall to see
  • You have the incorrect path to the proeworker.bat file in your agent.ini file
    • <Windchill>/conv/wvs/agent.ini

A couple of ways to debug:

  • look in the <Windchill>/logs/cadagent directory for log files
    • The log files contained under here will generally provide a good clue as to the issue
  • stick an "echo something to some file" in your proeworker.bat file to see if it is actually getting called ie:
    • echo Here at proeworker.bat >> c:\home\cadworker\proe_setup\startup.log
BenLoosli
23-Emerald II
(To:RandyJones)

Randy,

Not seeing anything out of the ordinary in any log files. Windows firewall is turned off due to it being a private network.

 

The GS Worker service starts automatically and this is the WorkerDaemon.exe. Is this also supposed to start/launch the proeworker,bat to start the workermonitor.exe process?

 

Everything works fine as long as I start the proeworker.bat file manually. What PTC and I could not resolve was how to get the proeworker.bat file to launch at system startup. It used to work fine until one day it just quit. IT has done no system updates for over a year, so we ruled that out. Maybe I need to see if they changed some system level setting that did not require a patch.

 

RandyJones
19-Tanzanite
(To:BenLoosli)


@BenLoosli wrote:

Randy,

Not seeing anything out of the ordinary in any log files. Windows firewall is turned off due to it being a private network.

 

The GS Worker service starts automatically and this is the WorkerDaemon.exe. Is this also supposed to start/launch the proeworker,bat to start the workermonitor.exe process?

No. The workermonitor.exe process is only started when something arrives in the publishing queue.

 

 

Everything works fine as long as I start the proeworker.bat file manually.

A couple of other things to look for:

  • What user is the WorkerDaemon.exe process being run as?
  • What user are you logging in and running the proeworker.bat as?

What PTC and I could not resolve was how to get the proeworker.bat file to launch at system startup. It used to work fine until one day it just quit. IT has done no system updates for over a year, so we ruled that out. Maybe I need to see if they changed some system level setting that did not require a patch.

Maybe changed the user the GS Worker service is being run as?

BenLoosli
23-Emerald II
(To:RandyJones)


A couple of other things to look for:

  • What user is the WorkerDaemon.exe process being run as?
  • What user are you logging in and running the proeworker.bat as?

Worker Daemon is being run from the default system account..

When I launch it manually I am using my own account which has local admin rights on the publisher.

Maybe changed the user the GS Worker service is being run as?

I used to use a dedicated account but stopped that when we installed Windchill 10 in April 2014.


 

TomU
23-Emerald IV
(To:BenLoosli)

Just to reiterate what Randy said, the proeworker.bat is used to start Creo and the worker monitor.  It only starts up when something needs to be published or you manually start it.  After the timeout period Creo will shut down but the worker monitor will stay running.  You can manually start and stop both of these from the Worker Agent Administration panel.

Worker Agent Administration.png

BenLoosli
23-Emerald II
(To:TomU)

On the publishing machine if I manually start Proeworker.bat, worker monitor starts.

When I submit a job for publishing, Creo launches and the file is created in Windchill.

From this standpoint, everything appears to be working and pointed to the correct pieces.

 

The system used to start proeworker automatically when the WorkerDaemon started. Creo would start and stop during the day as it was needed to publish jobs.

 

Then one day, it stopped starting. PTC said update to CreoView 3.1m030, no change. We had been on CreoView 2.0m040. Tried going back to CV2, still no autostart. Closed the call in hopes that CV4.1f000 used with Windchill 11.0m030 would allow the autostart to resume, no luck there.

 

What process triggers the proeworker.bat to run?

Is it the WorkerDaemon process from the GS Worker executable?

 

Has anyone else seen this issue?

It has done no updates to the system in over a year.

TomU
23-Emerald IV
(To:BenLoosli)


The system used to start proeworker automatically when the WorkerDaemon started.


I don't think this is correct.  I've certainly never seen this behavior.  The GS Worker Daemon is a service that listens to Windchill.  It does not start the worker monitor or Creo until instructed to do so from Windchill.  Starting this service should not automatically start anything else.

 

I'm wondering if you could customize the .bat slightly.  Maybe add a few extra lines to write something out to a text file.  Then you would at least know if the .bat file was getting called.  You also could turn on audit logging for this file and then see what gets recorded in the Windows log.

 

By the way, you can start the worker daemon manually without it running as a service.  Just to test, stop the service and then manually start the daemon with your local user account.  Go to Windchill and try to start that worker.  If the worker monitor and Creo successfully startup you probably have a permissions issue with the service account.

 

BenLoosli
23-Emerald II
(To:TomU)

I found this in a log file and have no idea what it means.

Log file is under Windchill logs\cadagent\GCEP006519-PROE1 folder and named GCEP006519-PROE1.log.

I tried to start publishing from the CAD Agent and it returned Failed to start. Log file said: Worker exe does not have any of the trusted prefixes.

 

Anyone know what trusted prefixes I need?

 

The batch files are all created by the Creo View Adapter setup program.

 

TomU
23-Emerald IV
(To:BenLoosli)

Yes.  You need to update some properties on the Windchill server.  See these articles:

https://www.ptc.com/en/support/article?n=CS140965

https://www.ptc.com/en/support/article?n=CS182327

BenLoosli
23-Emerald II
(To:TomU)

Thanks, Tom.

 

I also looked up the Dummys Guide thread on PTC/User to see what you and David had been referencing.

 

These changes must have come with 10.2, which is why I did not know about them as I went from 10.0 to 11.0.

 

BenLoosli
23-Emerald II
(To:TomU)

Added wt.auth.trustedHosts to wt.properties with the publishing machine IP address.

Added worker.exe.whitelist.prefixes to wvs.ppeoperties with c:/PTC which is where the Adapter code is located.

Still will not start when I try from my session.

Still get the worker prefixes error.

Tried started proeworker manually and it starts but now when I submit a job it fails, too with PROE cannot be started error.

 

Back to the manuals to try to figure out what PTC changed to screw everything up.

RandyJones
19-Tanzanite
(To:BenLoosli)


@BenLoosli wrote:

Added wt.auth.trustedHosts to wt.properties with the publishing machine IP address.

Added worker.exe.whitelist.prefixes to wvs.ppeoperties with c:/PTC which is where the Adapter code is located.

Still will not start when I try from my session.

Still get the worker prefixes error.

Tried started proeworker manually and it starts but now when I submit a job it fails, too with PROE cannot be started error.

 

Back to the manuals to try to figure out what PTC changed to screw everything up.


Despite what article CS140965 says:

https://www.ptc.com/appserver/cs/view/solution.jsp?n=CS140965

Using forward slashes will for the path separator will NOT work. You have to use back slashes:

c:/PTC (will not work)

c:\PTC (will work))

 

Example site.xconf entry:

<Property name="worker.exe.whitelist.prefixes" overridable="true"
targetFile="codebase/WEB-INF/conf/wvs.properties" value="c:\PTC" />

 

Translates to wvs.properties entry:

worker.exe.whitelist.prefixes \=c\:\\PTC

 

Keep in mind this prefix is the path to the directory (or a parent of this) which contains your proeworker.bat or whatever you have configured for "exe=" in the agent.ini file. This is not necessarily where you installed creo view adapters.


Translates to wvs.properties entry:

worker.exe.whitelist.prefixes \=c\:\\PTC


Correction the wvs.properties entry translates to this:

worker.exe.whitelist.prefixes=c\:\\PTC

TomU
23-Emerald IV
(To:BenLoosli)

What Randy said.

 

Here is how I entered mine:

xconfmanager -s worker.exe.whitelist.prefixes=E\:\\ptc -t /codebase/WEB-INF/conf/wvs.properties

If you have more than one worker, make sure you include all of the trusted hosts inside double quotes.

xconfmanager -s wt.auth.trustedHosts="192.168.21.11 192.168.21.23 tmmpceng02" -t codebase/wt.properties -p
jbailey
17-Peridot
(To:BenLoosli)

Have you tried to set the GS Worker Daemon to use a service account, and not a local account?  Also, have you enabled windchill to use Trusted Hosts?

BenLoosli
23-Emerald II
(To:jbailey)

Tried both and the worker still will not start automatically.

I have opened a call with PTC, but not holding my breath as it is the same support engineer who could not solve the issue when it first started last October while still on Windchill 10, which did not have the higher security settings.

jbailey
17-Peridot
(To:BenLoosli)

So our typical steps for setting up (I know yours stopped working- but this might help ring a bell)

  • Auth.properties file in <windchill home> with the authorized publishing user
  • Windchill props for trusted hosts - if worker is on a machine other than the WC server

   <Property name="wt.auth.trustedHost" overridable="true"

             targetFile="codebase/wt.properties"

             value="<ipaddress worker 1> <ip address worker 2"/>

 

   <Property name="worker.exe.whitelist.prefixes" overridable="true"

             targetFile="codebase/WEB-INF/conf/wvs.properties"

             value="C:\|c:\|D:\|d:\|"/>

  • If you are re-installing the worker (or installing a new worker), I always remove the GS worker daemon service from the registry and verify it is no longer in services, then install the CreoView adapter...
  • Set firewall rules for the in/out ports (I know you said you weren't using firewall)
  • Set the GS Worker Daemon user as a service account / or a network account to test
  • Set up share on the worker server (if different) where the worker will create temporary files.  Make sure you can get to the shared folder from the WC application server AND create a file using the service account from the previous step.
  • Configure the adapter - (run proe2pv_config.exe)
  • Make sure the setup directory is correct
  • Make sure the start command is <setupdirectory\proeworker.bat
  • In the Server host field, host.domain ex  mycoolPDM.mycompanyrules.net (no http/https, \Windchill, or port# here)
  • Enter the Server port - ootb will be 600, use the port you specified on the install
  • In Windchill. go to the worker agent administration
  • For host, don't use the FQDN ( so if it is cadworker.mycompanyrules.net just put cadworker) - obviously select Proe
  • Set where the worker location is setup (the windchill machine, another windows, etc)
  • Under execute command, ensure that it is the <creo setup location>\proeworker.bat    <<< double check this for spelling! This is usually where we foul up.  Set your startup time.  Our defaults are Startup time 30s, auto idle stop 60s, autobusystop 3600s, and AutoStart ischecked.
  • Specify the worker daemon port - ootb is 601, use the one you specified on install.
  • For common file system (files on another machine)
  • <networksharedpath\myworkerfolder> ex \\cadworker\SharedWorker\myworkerfolder
  • <cadworker> path - use the actual drive letter mapping here - ex c:\ptc\shared\myworkerfolder
  • Make sure to hit apply on the nexst screen
  • Make sure to Click "Save File" on the WCW Step 1 screen
  • return to worker agent administration
  • Reload workers
  • Go back to the worker machine, and open up the setup configuration... and run the Test tool to verify connection.
  • If you have multiple method servers, we set xconfmanager -s wt.queue.executeQueues=false -t \codebase\wt.properties -p

Sometimes we have had to restart the worker machine after initial configuration

 

jbailey
17-Peridot
(To:jbailey)

Sorry, had a mistake... when setting up the adapter...

 

The start command is the link to the parametric start batch file.  Make sure when you run the batch file - that creo ACTUALLY starts.

 

D:/ptc/<creo folder on server>/Creo 4.0/M010/Parametric/bin/<batch file to start creo>.bat

the bat file may or may not call out a psf file which specifies environment variables, license, etc...

 

Once you launch Creo using the batch file, I always try to connect to Windchill using the internal creo browser as the user specified in auth.properties.  One VERY important note.... this process needs to be prompt free.  No error messages, no java errors on the page etc.... We ran into this issue before where IT Security has changed IE policies on servers which disabled certain things (java, set compatability etc).  IF you cannot log in as the auth.proeprties user and get a clean, prompt free windchill after login- the worker will NOT work

Announcements


Top Tags