Forced Inactive Workspace While Working In Creo Parametric

[pstephens]

Hello All,

We have a user here with a long existing issue that we have not been able to resolve via PTC Tech Support.

The user is on PDMLink 10.1, M020 with Creo Parametric M090 (was still happening in M050, M070 and M100) and he experiences regular inactive workspaces.

He will be working away, then selects a function and is virtually kicked out of PDMLink and is greeted with the Windows Security pane to log back into Windchill.

We have tried numerous things to try to remedy, but it is still happening.

If anyone has experienced a similar issue and has a fix, we would really appreciate finding out how you did it.

The content from the most recent email from the user is below:

Images from his email are attached.

"Just got back to my desk, woke up my machine and re-entered my password to reactivate my PC.

In Creo, selected workspace and immediately received the “Window Security” logon AGAIN, and from past experience only means one thing “Inactive Workspace”.

Only way for me to reactivate the workspaces is to kill my Creo session and start again, this happened to me last week 4 times within half an hour, however this error does not only occur entering my workspaces, it has happened first thing in the morning starting Creo, changing from models to drawings (in session), even whilst working on a part, renaming, saving, and sending prints.

Every time PTC tech have ask me to try and replicate the issue it’s not possible … randomly occurs … PTC have taken logs and sent these to their R&D to no avail.

Cache, config setting and .ui’s has been blown away several times, tried swapping internet explorer to Mozilla but this creates further issues with other software in my machine."

Thanks

Paul

This thread is inactive and closed by the PTC Community Management Team. If you would like to provide a reply and re-open this thread, please notify the moderator and reference the thread. You may also use "Start a topic" button to ask a new question. Please be sure to include what version of the PTC product you are using so another community member knowledgeable about your version may be able to assist.

[dschenken]

I think the login is held as a cookie. I believe that's how Windchill knows when you've logged in or not. I have seen other places that to switch users in the browser can be done by deleting said cookie(s).

With no access to the PTC code, it's only a guess that something is wiping the out the cookie, forcing the need to log in again.

You don't mention what browser is being used. I haven't anything specific in mind, but that's where the cookies are stored and maybe others will notice something about the particular browser. Also, Windows version would be a clue as well.

What happens to the user if he changes to 'offline' except for specifically using the connection to Commonspace?

[TomU]

We struggled with this a bunch back on 9.1 M050. The issue seemed to occur primarily for users who had larger workspaces (> 1000 objects). We worked with tech support for 9 months on this issue. We tried different browsers, different config options, custom registry changes, and many other things. No solution was ever found.

6 months later (after closing the case) we moved to Windchill 10.2 M010 (and then M020). To the best of my knowledge, this has not reoccurred since the upgrade.

[pstephens]

Thanks David and Tom for taking the time to reply.

The cookies angle mentioned by David triggered us to check the user's IE 8 settings.

He had the “Delete browsing history on exit” checked.

A couple of others, me included, had that box unchecked and we do not have the error.

I have got the user to uncheck the box and test today.

We have just this minute received this reply from Tech Support which indicates that David's answer is correct.

"As per previous comments as well as attached fiddler logs, it looks like the issue may be related to the missing WF-* cookies. Could I please ask you to check the following settings:

1) Go to IE, Internet Options, Privacy Tab, click on Advanced button. Please verify that the checkbox is unchecked in "Advanced Privacy Settings" dialog.

2) Go go to Internet Options, Security Tab. Please verify that "Enable protected Mode" is unchecked for "Local intranet". Alternative suggestion, would be to try to uncheck Protected Mode" for Internet as well, as per http://support.microsoft.com/kb/932118

3) It would also be a good idea to verify, the logged in user has read/write permissions to cookies folder [C|D]:\Users\<user>\AppData\Roaming\Microsoft\Windows\Cookies"

4) Are there any automated anti-virus scans running on client that could potentially impact cookie storage?"

We will try that and mark David's answer as correct in the New Year once we have confirmed that as a fix.