Config file problems

[ptc-2151062]

To all you Windchill users:

We are on Windchill 10.0 M030, Creo 1.0 M050.

I recently updated the config file for all users (all are stored locally on each users C drive). The previous config file worked fine for all users.

The new config file is basically the same, with a few new options. For one of our users, after Creo startup, Creo will hang indefinitely (after user is prompted for the Windchill user/pass). This user is running on Windows 7, though the rest of the users also use either Windows 7 or Vista with no issues.

I can circumvent this problem by removing all the following config options that have the file path starting with wtpub://Windchill… :

template_designasm wtpub://Windchill/Libraries/Library/Formats/in_lbs_assembly_solid.asm

template_sheetmetalpart wtpub://Windchill/Libraries/Library/Formats/inlbs_part_sheetmetal.prt

template_solidpart wtpub://Windchill/Libraries/Library/Formats/inlbs_part_solid.prt

pro_format_dir wtpub://Windchill/Libraries/Library/Formats

start_model_dir wtpub://Windchill/Libraries/Library/Formats

pro_palette_dir wtpub://Windchill/Libraries/Library/Symbols

symbol_instance_palette_file wtpub://Windchill/Libraries/Library/Symbols/standard_notes.drw

Note, however, that the old config file also contained most of the above options, yet there was no hang after startup.

I have attached the old and new config files.

Anyone have any ideas?

Andri Ulrich

[PascalDICHELLO]

Hello,

I see that you use Mozilla Browser.
Did you try to delete the file on the pc user :

C:\Users\xxx\AppData\Roaming\ptc\.ptcmXXXX

Pascal

[ptc-2151062]

Pascal,

deleted file you suggested (C:\Users\xxx\AppData\Roaming\ptc\.ptcmXXXX), and also deleted the .wf folder (C:\Users\<USERNAME>\AppData\Roaming\PTC\ProENGINEER\Wildfire).

Restarted Creo with the new config file, re-registered with Windchill. Creo then ran fine, with the new config settings and all.

However, upon Creo shutdown and subsequent restart, same issue.

Andri

[ChrisCollinson]

Hi Andri,

Starter for 10, all the options that you removed should be in the config.sup file as they are static, so all the template, format, unit settings, this cannot be over ridden by any other config file

Next I would check that Creo is starting up in a folder that the user has permission to write to, right click on the creo icon and see where it says "Start In" check that this is available and not read only.

If the user is not getting any further than the log in screen it could be Windchill is trying to sync the users workspaces but is not able to write/create the workspace.

The settings in your config, you can bring in one by one and see if there is one in particular that causes the issue or if it is a Windchill connection issue

Hope this helps

[ptc-2151062]

I opened a case with PTC on this. They were not of much help, but I ended up figuring out a workaround.

All our config files have the line:

windows_browser_type mozilla_based_browser

After removing this line, the problem went away for the user. Firefox was installed on this particular machine, but perhaps it was an old version... or some other issue.

In any case, the reason this config option was set to begin with was because our reseller suggested it to improve performance with Windchill:

"The reason we usually recommend setting the browser to Mozilla in Wildfire 5 / Creo Elements Pro 5 is that with systems running Internet Explorer 7 or 8 it performs noticeably faster and is typically more stable with Windchill 10.1. In fact for many of our customers it corrects issues with lock-ups. If your systems were updated to Internet Explorer 9 or 10, then using Internet Explorer would be better, and is actually much better with IE 10. However, according to PTC IE 10 is only supported on Windows 8 systems."

Clearly in this case it was causing the lock-ups, so I have removed it and now everything works fine!

Andri

[jessh]

I believe that the mozilla-based-browser here is not whatever nice, new Firefox you might have installed, but rather Gecko libraries shipped with Wildfire/Creo. Thus I don't think it matters which Firefox you have or haven't installed, but rather which Wildfire/Creo version you're using and how up-to-date they've managed to get the Gecko libraries therein.

[ptc-2151062]

Jess,

that's the odd thing - no changes were made to WIndchill or Creo and one day that config line starts causing problems. As a matter of fact, it just happened again on a workstation which was running the config file with the mozilla bowser type option just fine - then today Creo stalled after login. Removing the browser type option from the config file once again fixed the issue.

Unless all these users (3 total now) are somehow messing up their 'Gecko' libraries on their systems, I can't explain why this config option suddenly causes problems.

Andri

[jessh]

Perhaps Creo uses Gecko via shared libraries and these particular users did something that placed other versions of some of the Gecko libraries into the PATH used by Creo? That could certainly louse things up.

[slapha]

We're on Creo 2 M050, WC 10.1 M030. Our users have experienced not responding on startup after a crash too.
In many cases for us, we found the text/config.pro and text/config.sup was being merged down into the user's startup config.pro.

This caused our JLink apps to be loaded twice and causing a conflict. Sometimes it would throw a toolkit error, other times it wouldn't.
Fixing the startup config.pro solved that problem. We have an open ticket with PTC on it, but they gave us this article as a reason
(https://www.ptc.com/appserver/cs/view/solution.jsp?n=CS104667).

We've also experienced it in a few other cases but we haven't come to a solid answer. PTC's answer was "Just use Mozilla", until we had issues with Mozilla too. Things that have helped: Fewer models in workspaces, Fixing compatibility mode for IE, Enabling native XMLHTTP support for IE. They also gave us a set of config settings that might help (we already had most implemented) dm_network_request_size=100000, dm_http_compression_level=0, windows_browser_type=mozilla_based_browser, dm_network_threads=4, dm_synchronize_in_background=yes.

Something else I found that didn't apply to us but might help "Set the proxy settings similar to the Firefox (Mozilla browser) settings".

[ptc-2151062]

Steven,

PTC recommended to me the same config settings you mentioned - dm_network_request_size=100000, etc.

How did these settings help? I ran them a couple of times and didnt notice any difference in Windchill operation.

Andri

[slapha]

We were already using the network settings. The mozilla settings seem to help those that were using Mozilla. We've also had some issues with the browser locking up with IE 9 and Windchill 10.2. This was resolved with setting the browser to always check for a newer verson of a webpage every time it's visited and preventing compatibility view.

[LoriSood]

Are you getting prompted to log in upon start up when the config.pro options are pointing to Windchill? Is there a possibility that the log in window is popping up behind the screen, thus giving the appearance of hanging when all it's doing is waiting for the log in credentials?