Hi Chuck,

First question that comes to mind is where was the actual 'xyview.exe' process running - was the process running directly on the Mac or was it running in a "remote desktop" session where that session where the process would actually be running on the "XPP server"?

Does "Microsoft remote desktop for Mac" not let you reconnect to a session from which the user got disconnected (in this case by the user's computer crashing)?

I would think that this should be possible and then the user should be able to reconnect to that "remote session" and continue where they left off (i.e. the xyview editing session should still be running in that session).

If that's not possible, then to release the lock on the job.dpd file you'll have to 'kill' (terminate) the xyview.exe process that's running on the server. You'll have to go to the server to do that.

The challenge is probably determining which xyview.exe process has the lock on that particular job.dpd file if there are other users editing other divisions.

I'm not familiar myself with what tool/utility is available on Windows that might tell you which process actually holds the lock on a particular job.dpd file - but I would think there might be something to do that.

I wasn't talking about the user just connecting again to the server with a new (remote) session, I was talking about that user reconnecting to the existing remote session.

When I use Remote Desktop to create a "session" on a remote system (albeit from a Windows PC), if I get disconnected from that session for any reason (such as PC crash or network/internet/VPN outage) I am later able to reconnect to that same Remote Desktop session and continue as if the "disconnect" never happened.

If you don't have "Microsoft remote desktop for Mac" (or Terminal Services on the server) set up (or enabled) to be able to do that (assuming it's possible), then I suggest that you look into that as an option to alleviate this problem going forward. I think even for (regular) Remote Desktop it has to be enabled/set (probably on the server) for a user to be able to reconnect to a session.

There has to be some process still running somewhere that still has the job.dpd file locked; otherwise the server system would have "released" the lock on the file (I'm assuming that the job.dpd file resides on the server).

Maybe someone else will have some other suggestions.

I believe her Xyview crashed on the Windows Server, just like it has on our unix system. The remote session did not disconnect, or crash, so there is no "ghost" remote session to reconnect to. In Linux I would just look for a process marked "defunct" and kill that process. On windows, I cannot see all processes for all users to look for a locked process, because I'm just one user and can only see my own Windows processes.

If it was true that the user's Xyview actually crashed and the process no longer existed in any form, then the "system" would have released the lock on the job.dpd file. A job.dpd lock (of the type being used by XPP) cannot continue to exist if the process that locked the file is actually "gone".

So as I said before there has to be a (xyview.exe) process (in some state) still running that's holding the file lock.

I've seen in Windows that when an app crashes, the user is prompted to do something (like report it to Microsoft or stop the process) and if the prompt is not clicked away then the "process" is still running.

An "Administrator" should be able to log in to the XPP server and should have permissions (or should be able to run with full permissions if UAC is getting in the way) to see "all" tasks for all users.

The error message XPP is giving is "Cannot access Job - Files in Use". Will we have to reboot XPP every time a Mac crashes XPP?

At the Windows OS level I was able to find a list of locked files under Control Panel, Admin Tools, Computer Management/ System Tools/ Shared Folders/ Open Files. I found the job.dpd file was locked in the division Lu told me about, released the lock, but she still can't edit the division.

Maybe I'll have to file a case for this.

I see that you did open up a Case with support; that was the right thing to do at this point.

I will note that in the screen snap you provided of the Computer Management/System Tools/Shared Folders/Open Files utility, that it shows a job.dpd file listed with #Locks = 0 (by another user "lgearheart", and not the highlighted "lthompson" user).

There is more than one type of "lock" on files, and I'm doubtful that this utility is showing the kind of lock that's used by XPP on the job.dpd file (and other files that are locked by XPP). If the utility was showing the right kind of locks (used by XPP) then each job.dpd listed should have #Locks set to > 0 on them.

And as I mentioned with the type of locking used by XPP, if the process owning the lock is still around (in any form) then I don't think there's anything you can "run" to release the lock other than something that completely "kills" that process.

I  see Support suggested the Handle utility might help. That's a command-line based tool. There are also GUI-base tools like Process Explorer and Process Manager that might be of use.

I see that you did open up a Case with support; that was the right thing to do at this point.

I will note that in the screen snap you provided of the Computer Management/System Tools/Shared Folders/Open Files utility, that it shows a job.dpd file listed with #Locks = 0 (by another user "lgearheart", and not the highlighted "lthompson" user).

There is more than one type of "lock" on files, and I'm doubtful that this utility is showing the kind of lock that's used by XPP on the job.dpd file (and other files that are locked by XPP). If the utility was showing the right kind of locks (used by XPP) then each job.dpd listed should have #Locks set to > 0 on them.

And as I mentioned with the type of locking used by XPP, if the process owning the lock is still around (in any form) then I don't think there's anything you can "run" to release the lock other than something that completely "kills" that process.

I  see Support suggested the Handle utility might help. That's a command-line based tool. There are also GUI-base tools like Process Explorer and Process Manager that might be of use.