"Cannot ACCESS job" error message on Windows

You all probably have seen the following error message when trying to open up a division:

But the system is not very helpful in telling you who or why your division is "in use".
Maybe there is a co-worker that has the division open for the moment. Or somebody is running a citi or compose process on the entire job. Or maybe somebody is printing the job or division.
Or maybe there is a hung process.

If you are running XPP on a unix (linux) system, you are in luck.
You (or your sys admin) simply runs the "divuse -p" command on that division and the system will give you the USER name and the PID of the process that holds the lock on the division.

But on Windows the -p or -P switches are not supported (see https://community.sdl.com/ideas/contenta-ideas/i/ideas-xpp/extend-the-divuse-tool-on-windows-to-include-the-user-and-pid-info)

Here is a procedure you can use to find out the PID and USER that has a lock on the division.
The only difficult part is that you first will have to 'guess' what is the process that has a lock (xyview, compose, psfmtdrv, divpdf,..)
There is a  Windows tool that can tell you that called Handle (https://docs.microsoft.com/en-us/sysinternals/downloads/handle), but then your sys admin will have to install this and you probably will not get the privilege of using or running this tool. You can always ask nicely your IT departement but the answer will probably be 'NO'.

But let's assume that the division is kept open by another xyview process. (just for simplicity)

You then open a powershell window and do the following:

This will give you a nice list with all xyview's running on your system combined with their PID and the division they are working on.

From that list you can find out what is the Process ID (PID) of the xyview that has your division open.
If you are in a hurry and you do not care if you upset your co-workers or not, you could kill the PID in question, but that could lead to a loss of work.
It is probably a lot nicer to try to find out who is the user that has your division open, so you can ask if he can close the division because you want access.
Unfortunately find the user is a bit more complicated.
Here we go:

On the first line we store ALL the output of the Get-Process tool into the variable A by using the command: $A = Get-Process -ID ### (the number of the PID you are interested in)
We then dive deeper into that info and ask for the StartInfo and from the StartInfo we want the Environment (hence $A.StartInfo.Environemt)
This will dump the complete startup environment of the xyview and in there you find the USERNAME.

I know a lot of work just to find the name of the user you should talk to...

Do you know an easier way preferably without having to install extra tools or utilities?
Please comment below if you do!


  • I've done a little reading and the Windows API does not give you access to the user information. There are references to the fact that "sysinternals" does it by using undocumented API calls in "nt.dll" so that is not available to us.

    The command "openfile" is built into modern windows, and will give you a nice list of open (locked) files, but you have to enable it, and the documentation warns that there will be a "speed" impact; i.e. Windows keeping track at this level slows things down. I dont think this would be good.

    Building on what you have shown, you can actually use "resmon" to get the list of open "job.dpd" files which is the file that xyview/compose uses to lock the Division. "resmon" is the Resource monitor that is accessible from the Task Manager or from just running it from "run" and does not require admin privileges or a command prompt to see the information.

    You select "CPU" and "Associated Handles", and search for "job.log". It will show the "pid" of the process that has it opened. Unfortunately it does not show the user name. From there, the trick to get the user name will work.

    Here is a sample on my XPP with one xyview open.

  • Thanks Steve for tuning in. 
    Resmon does seem to do the job and eliminates the guessing on what exactly is holding the lock on your division.
    So very good suggestion. 

  • So the answer to your original question is: "no, there is nothing we can do to 'divuse' because we can't get the information we need". While not optimum at least there is a way on Windows to figure it out.

  • Hello, 

    A more Windows-y approach would be to use an MMC with an account that has been granted elevated privileges on the application server:

    Once you have a blank MMC open, Add/Remove the Shared Folders Snap-in.

    Specify your server name along with the radio button next to Open Files.

    Click OK and then on the Open Files to display the files open on Your-Friendly-XPP-Server. Sort by the path to ID the user and either:

    • inform the user they've locked something they need to exit, or
    • select one (or all) of the files associated with the job you're trying to free up > right click > close open file. 

    Since the MMC is already a part of Windows - there's nothing to install and I.T. might only need to grant the necessary permissions for a "special" user to run this MMC on the application server(s) and close files. 

    Hope this helps
    - Thomas