Paradox Community

Items in pnews.paradox-interactive

Subject:Re: Paradox crashing on terminal server leaves application unrunable
Date:Thu, 1 Dec 2016 09:54:42 -0500
From:Jim Moseley <>

For Process Monitor, start it before trying to start your app.  Then, 
Add a FILTER on 'Process Name' of PDXWin32.exe.  Then, start your app. 
This will show you every file access that happens.  You can then save 
that trace as a CSV and email it to me at jmose (at) NOSPAM dot 
triptracker dot com (without the nospam), and I'll see if I can spot 

My guess is that one of the last file accesses will point to where your 
problem is (my bet is PdoxUsrs.LCK or PdoxUsrs.NET).

Also, A. I. Breveleri wrote a utility years ago called Lockwise.  If you 
run that from the NET DIR folder after the first crash, it will probably 
show corrupt users.  You can also then right-click it and choose 'Open 
Directory Lock Display' to see what is in the PdoxUsrs.LCK files, which 
might point to corrupt locks.

FYI, here's a link to it from my site, if you can't find it:

Finally, once the first user crashes, are you able to manually delete 
these files?  If not, what error do you get?
- %NETDIR%\PdoxUsrs.NET
- %WORKDIR%\PdoxUsrs.LCK
- %WORKDIR%\Paradox.LCK

Jim Moseley

On 12/1/2016 12:37 AM, Royce Lithgo wrote:
> The event is the same whether its the first user crash or other users
> trying to get in.
> When other users try to get in, sometimes paradox launches but it is in
> a corrupt state. For example, the File, Open menu is gone. Also it
> doesn't launch our menu form which is set by command line. Other times,
> paradox immediately crashes on launch.
> We never see a table is locked error as you mentioned.
> I've tried using process monitor to look for dead paradox processes but
> there aren't any. I guess i could try searching for pdoxusrs to see if
> there are any open handles on that.
> On 1/12/2016 3:06 AM, Jim Moseley wrote:
>> Royce,
>> Is this event from when the first user crashed, or when the other users
>> try to get back in?
>> What happens on the other users' computers right after the first user
>> crashes?  Do they freeze, get kicked out of Pdox, or just end up with a
>> 'table is locked' error?
>> I have a similar issue with Pdox 9 on later Win Servers, and not just
>> with Terminal Services.  Once a user 'crashes' Paradox, it corrupts the
>> PdoxUsrs.LCK file.  Then, all the other users start to 'spin' as they
>> call it, eventually receiving a 'table is locked' error if they wait
>> long enough.  (I've even seen it drop their shared drive network
>> connection, which might be a cause or effect of this issue.)
>> You can trace what is happening using the Process Monitor tool from
>> Microsoft.  Just filter it to the Paradox process, and it will show you
>> all file accesses, and whether they were successful.  In my case, it
>> shows repeated attempts to write to PdoxUsrs.LCK, which all fail.
>> This is also why you have to reboot.  You can't delete PdoxUsrs.LCK
>> because it is being used, even if you've forced every network share
>> session closed on Computer Management.  The issue is that the service
>> called 'System' is still holding on to this file.  That service is the
>> NetSVCS service, which handles file sharing.  It typically won't let you
>> shut/disable that service, since it is busy trying to fulfill old
>> requests.
>> HTH,
>> Jim Moseley
>> On 11/29/2016 6:07 PM, Royce Lithgo wrote:
>>> This is really driving everyone crazy. It seems that when paradox
>>> crashes for a single users on our terminal server, the application can
>>> no longer be run by anyone and the server needs a restart. The
>>> application event log has these events:
>>> Faulting application name: PDXWIN32.EXE, version:, time stamp:
>>> 0x60c220a3
>>> Faulting module name: PXSRV32.dll, version: 6.3.9600.18233, time stamp:
>>> 0x56bb4e1d
>>> Exception code: 0xc0000142
>>> Fault offset: 0x0009d3c2
>>> Faulting process id: 0x3c84
>>> Faulting application start time: 0x01d24a8a404094ce
>>> Faulting application path: C:\Program Files
>>> (x86)\Borland\Paradox\PDXWIN32.EXE
>>> Faulting module path: PXSRV32.dll
>>> Report Id: 8433d39c-b67d-11e6-811f-00155d1e4601
>>> Faulting package full name:
>>> Faulting package-relative application ID:
>>> I'm not sure why exactly a restart is required. Sometimes if the user
>>> who crashed logs out, the issue is resolved. But usually no one owns up
>>> to being the one who crashed it and they don't follow the procedure (of
>>> logging out immediately after a crash).
>>> Is it possible that PXSRV32.dll somehow gets corrupt as is still
>>> resident in memory even though there's no PDXWIN32.EXE processes
>>> running?

Copyright © 2004