|Subject:||Re: Paradox crashing on terminal server leaves application unrunable
|Date:||Thu, 1 Dec 2016 09:54:42 -0500
|From:||Jim Moseley <firstname.lastname@example.org>
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?
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:
>> 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
>> 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: 184.108.40.206, time stamp:
>>> Faulting module name: PXSRV32.dll, version: 6.3.9600.18233, time stamp:
>>> Exception code: 0xc0000142
>>> Fault offset: 0x0009d3c2
>>> Faulting process id: 0x3c84
>>> Faulting application start time: 0x01d24a8a404094ce
>>> Faulting application path: C:\Program Files
>>> 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