APPX/NT Operations and Administration

Note: The information here is generally obsolete since WinAppxD has been replaced by the APPX Login Manager.

Contents:

1. Care and Feeding of WinAppxD
2. APPX Client/Server session management
3. Other NT Operations and Administration Issues

I. Care and Feeding of WinAppxD

1. What is WinAppxD, and what is it used for?

2. How can I verify that WinAppxD is running?
3. How do I start WinAppxD?
4. How do I stop WinAppxD?
5. Is it safe to stop WinAppxD, if I'm going to need to restart it again without rebooting my server?

6. When might I want to stop and restart WinAppxD (either with, or without, a reboot)?

7. My WinAppxD gets stuck regularly. As you say above, sometimes I can restart it without a reboot, and sometimes I can't. I don't have time for reboots in the middle of the day. What can I do?

II. APPX Client/Server session management

1. A user has just called me to say that they are hung. What should I do?
2. The user process is hung, and I haven't been able to resolve the problem, so I need to kill that client/server session. How do I do that?
3. How do I manually kill an APPX server process?
4. A user just called me to say that her APPX Client window just disappeared, or there was a power outage or system malfunction, that caused their APPX Client session to end unexpectedly. Do I need to do anything?
5. All of my users except for one have gone home for the night, and I am sure they have turned off their PC's. I still see three (or four, or ten) APPX.EXE processes in the server's task list. Why are they there?
6. How can I determine which APPX.EXE processes on my server are orphans?
7. That command-line "kill" mechanism is too time-consuming and error-prone. Is there a better alternative?

8. I look in my NT task manager and see that an APPX.EXE process is consuming 95% (or more) of the CPU. Why do I get these runaway processes?

III. Other NT Operations and Administration Issues

1. Printing to a printer produces blank pages.

2. File fragmentation

I. Care and Feeding of the WinAppxD Service

1. What is WinAppxD, and what is it used for?

WinAppxD is the NT implementation of <APPX name for this functionality>. Its purpose is to monitor a user-defined port number for connection requests from clients, such as the APPX Client or AppxNET (used for APPXODBC across the network as well), then validate the client's login and password, and start an APPX Server session connected to that client.

After the user authenticates and is connected to a server-side APPX session, WinAppxD has nothing further to do with that client/server session. If WinAppxD is killed, ends with an error, or experiences a hung port, this will not affect users who have already established APPX client/server connections. (A problem with WinAppxD is the most common cause of the error situation in which no new users can login, but users who are already logged in, can continue to work.)

2. How can I verify that WinAppxD is running?

Bring up the NT Task Manager. Look for a process named WinAppxD.exe. If you see it, WinAppxD is running. (Note: this does not necessarily mean that WinAppxD is running properly, as a WinAppxD with a hung port will still appear in the task manager. This is mainly useful to do, to verify that WinAppxD is at least starting successfully.) If this process is not present in your task list, client logins cannot be accepted on your APPX server.

3. How do I start WinAppxD?

WinAppxD is normally started automatically by the system when it boots. See this document for detailed Installation and Configuration instructions.

If you don't want WinAppxD to start automatically (for example, if you wish for the system to boot without allowing APPX logins), you can set the Startup Type for the WinAppxD service to "Manual" in the NT "Services" Control Panel applet. Then, you can reboot the system. If you check the NT task list at this point, you should not see WinAppxD in it. To manually start WinAppxD, go to the NT "Services" Control Panel applet again, select WinAppxD, and click "Start". Wait a moment or two, then bring up the task list and verify that it is there. (You must be logged in as Administrator to do this.)

4. How do I stop WinAppxD?

WinAppxD automatically stops when the system is shut down or on its way to a reboot.

If you want to manually stop WinAppxD before that point, you MAY be able to stop it through the NT "Services" Control Panel applet, by selecting WinAppxD, and clicking "Stop". Wait a moment or two, then bring up the task list and verify that it is no longer listed.

If after several minutes, you still see WinAppxD in the task list, you can try a more "drastic" measure and try to "End Process" the WinAppxD.exe entry in the task list.

It's several minutes after that, and it's still there? The most drastic way of stopping WinAppxD, if you have the NT Resource Kit installed, is to use the kill.exe command provided by the Resource Kit. (Hint: You probably have this installed, since some utilities from it are required to install and run WinAppxD. Do a Find for "kill.exe" if you can't locate it.) (You must be logged in as Administrator to do this.)

5. Is it safe to stop WinAppxD, if I'm going to need to restart it again without rebooting my server?

MAYBE. Sometimes you can stop WinAppxD, then manually start it again, and everything will work fine. However, sometimes the manual restart process is not successful. This appears to be due to NT not properly releasing the port (usually 8060) when WinAppxD is stopped. If the port is not released, when WinAppxD restarts and attempts to recapture it, it can't, so client logins won't be accepted.

(See question #7 below ("My WinAppxD gets stuck regularly ...) for a workaround to this.) It may be a very good idea to set up Multiple WinAppxD servers as per #7 from the get-go, as a fallback position, in case you unexpectedly get a hung port condition.) If the restart fails, you can try stopping WinAppxD again (if one started during the restart process) and restarting it again. If a WinAppxD.exe does not reappear in the task list, or if it appears but client logins are not accepted, at this point, your only option is to reboot.

We don't have any figures as to what percentage of the time this is and is not successful. In general, if you stop a WORKING WinAppxD, and expect to be able to restart it without a reboot, YOU ARE TAKING A CHANCE. It may or may not work, due to NT. If you stop a malfunctioning WinAppxD in the hope that restarting it will resolve the error condition without a reboot, you have nothing to lose. In that case, it is definitely worth a try. (You must be logged in as Administrator to do this.)

6. When might I want to stop and restart WinAppxD (either with, or without, a reboot)?

If you experience the following scenario on your network, you probably need to stop and restart WinAppxD:

• • Existing users can continue to work in APPX.

  • Clients now trying to login to APPX hang after entering their login information. (APPX may eventually come back and say, Cannot connect to host.)

  • Having a user logout, and try to log back in again, to make sure that the situation is not due to exceeding your licensed user count, results in that user not being able to log in.

  Also, if you bring up an NT task list, and do not see WinAppxD.exe in the list, that is an indication that it has already stopped (either you stopped it, or it ran into an error condition and ended itself), and needs to be restarted.

  Once again, restarting WinAppxD without a reboot is not guaranteed to work, due to NT TCP/IP implementation. The existence of "Stop" and "Start" buttons in the Services Control panel applet does not mean that these functions work 100% of the time.

  7. My WinAppxD gets stuck regularly. As you say above, sometimes I can restart it without a reboot, and sometimes I can't. I don't have time for reboots in the middle of the day. What can I do?

  Many customers have increased the availability of WinAppxD by installing multiple WinAppxD services (WinAppxD as originally installed, plus nearly exact copies of it as WinAppxD2, WinAppxD3, etc.). These differ only in the port used by each one. For example, WinAppxD may listen on port 8060. WinAppxD2 may listen on port 8061. WinAppxD3 on port 8062. Once you have set up multiple WinAppxD services, you can instruct your users to change their "Server Port" (in the login dialog) to one of the alternate port numbers, if they experience difficulty connecting to the default port number.

  You may wish to copy WinAppxD.exe to names like Appx8060.exe, Appx8061.exe, etc., in order to keep them grouped together under NT Server's Task Manager.

  In any case, we recommend that you run multiple APPX/Servers, due to the increased level of fault tolerance it provides. Instructions on setting up WinAppxD services are in the APPX Presentation Client/Server Installation Guide.

  Multiple WinAppxD services on different ports invoked from batch files is also a way of changing the main environment variables for, for example, running two versions and data sets in parallel, or using a different APPX_KEYMAP when attaching from another device type such as handheld RF scanners through a telnet session via a LINUX box.

  II. APPX Client/Server session management

  1. A user has just called me to say that they are hung. What should I do?

  First, have the user tell you the number that appears in their APPX Client title bar. This is the NT PID (process ID) of the SERVER process to which they are connected. Go to your server, and verify that there is an APPX.EXE process with that PID on your system in the task list.

  If there is no process listed in your server's task list with that number, double-check with the user that you're looking for the right one. Once you are sure that it isn't there, you have a situation in which the client process exists and the server process doesn't. Instruct the user to "End Task" on his APPX Client session via the Windows Task Manager. It may pop another box up, saying that the process is not responding. Instruct them user to click "End Task" on that box as well.

  If the server-side process does appear in your server's task list, then you have more sleuthing to do.

  Find out what the user was doing. Do they see any error messages on their screen? What process are they in? How long have they been waiting for a response from the system?

  Try to find out if they are doing anything that requires locking a record (they probably are). (The user himself may not know the answer to this. Refer to your application for the final word.) If so, try to find out if that record is likely to be held by another interactive user, or perhaps a JOB that is batch updating a series of records. In many instances, even if the user does not receive a message to the screen, the culprit of these hangs is that their process is trying to access a record held by someone else. (If, for example, the INPUT calls an UPDATE as an automatic process, and that UPDATE runs into a locked record, it will silently wait for that record to become available, without advising the user.)

  If it is possible that they are waiting for a lock, check with other uses and see if you can discover (and then eliminate) the source of the lock conflict.

  BJUtils (mentioned in item II.7 below) contains a couple of methods for determining who has which files open. While it cannot tell you who has which records locked in which files due to NT O/S design limitations, it can point you in the right direction.

  Remember also that the system might just be slow. Check to see what system performance is like, before assuming that their process is actually paused, as opposed to just running slowly.

  If you were unable to narrow the situation down to lock contention, and solve it, and are also certain that the process is not just running slowly, it is time to look at killing the process.

  2. The user process is hung, and I haven't been able to resolve the problem, so I need to kill that client/server session. How do I do that?

  First, have the user try again to END and CANCEL out of their process, to make sure that it is not possible to resolve this any other way.

  Have the user tell you the number which appears in their APPX Client title bar (they've presumably done this already, but in case they haven't, now's the time to ask). That is the NT PID (process ID) of the SERVER process to which this client is connected.

  Once you have the PID, but not before, instruct the user to bring up their Windows Task List, and select the APPX process, then click on "End Task". It may pop another box up, saying that the process is not responding. Instruct the user to click "End Task" on that box as well.

  Wait a minute or two for an orderly shutdown of the server-side process connected to the client. APPX should detect that the client has disappeared, and end the server process.

  If after waiting several minutes, you still see the server-side process ID in your NT server's task list, you will need to manually kill the server-side process.

  3. How do I manually kill an APPX server process?

  In many instances, an APPX server process may be killed by doing the following:

Go to the server on which WinAppxD and the APPX server processes run, and log in as Administrator.

Bring up the NT task list, and look for an APPX.EXE listed with the process ID you want to kill (usually, this will be one given to you by the user, from their client's Windows title bar)

Highlight it and click "End Task".

If another box pops up, saying that the application is not responding, click "End Task" there as well.

Hopefully, this will result in that process disappearing from the task list. If a process refuses to be killed in this way, it is time to take more drastic measures.

If you can't kill the process via the Task Manger, try using the NT Resource Kit's "kill" command. (You probably have this installed, since some utilities from it are required to install and run WinAppxD. Do a Find for "kill.exe" if you can't locate it.) The Resource Kit "kill" command is very effective, and using it is expected to kill the process even if the Task Manager method did not. (You must be logged in as Administrator to do this.)

4. A user just called me to say that her APPX Client window just disappeared, or there was a power outage or system malfunction, that caused their APPX Client session to end unexpectedly. Do I need to do anything?

It would be a good idea to verify that the server-side process attached to that client session has terminated, and if not, kill it manually.

5. All of my users except for one have gone home for the night, and I am sure they have turned off their PC's. I still see three (or four, or ten) APPX.EXE processes in the server's task list. Why are they there?

ONE will be there, because it is the APPX License Server. Some installation maintain a separate copy of appx.exe called something like AppxLicS.exe and invoke this copy to start the License Server. This keeps the task separate from (but close to) the group of APPX tasks in the NT Task Manager's list."

At least one other server side process will be there to service your remaining user's connection. (If the user has more than one APPX Client session running, there will be one server side process for each Client session.)

Generally, the others are there because users did not properly exit the APPX client (END'ing until the APPX Client window disappears). For example, they may have just hit the power switch or executed shutdown on their PC without properly exiting APPX. In the APPX world, we refer to these leftover server APPX.EXE's as "orphans".

It is probably a good idea to look for and kill orphan processes from time to time, particularly if your system goes days or weeks without a reboot (which would remove the orphans).

If you're running APPX 4.0.a or higher, you should set environment variable APPX_LS_GHOSTS=True. This will cause the APPX License Server to perform periodic cleanup of the APPX usage register, and may help keep the number of orphaned sessions down.

6. How can I determine which APPX.EXE processes on my server are orphans?

"View Registration usage" within the System Administration Registration editor, in APPX versions 4.0.a and higher, will let you view PID (Process ID) by User. Once you have identified which processes on the server are orphans, you can kill the using the standard mechanisms described earlier.

7. That command-line "kill" mechanism is too time-consuming and error-prone. Is there a better alternative?

A well-known APPX user, Bruce Johnston, has put together a suite of utility processes he uses in the day-to-day administration of his APPX server. One of these utility processes is a "kill" utility reminiscent of similar functionality found on Wang systems.

While ASI has not tested and in no way warrants this software, it has been available for some time now, and we have heard no negative feedback regarding it. You might want to check it out at www.cansyswest.com/nt_utilities.htm and see if serves your needs.

Please be aware that if you install this package, ASI cannot provide support for its functions, since we did not write it. (Caveat emptor, and all the other precautions that normally go along with free and/or user-supported software).

8. I look in my NT task manager and see that an APPX.EXE process is consuming 95% (or more) of the CPU. Why do I get these runaway processes?

A process using large amounts of CPU is not likely to be a "runaway" in the sense that it is malfunctioning, and is out of control, taking over your computer.

What IS likely, though, is that it is an OUTPUT, or UPDATE, or some other process which takes a while to run, and does lots of I/O and/or data processing. (Designers, Cross Reference has been known to do this when run across multiple large apps).

Until the process finishes, it will likely keep using a large percentage of CPU time, simply because that is how NT chooses to allocate CPU time. (The strategy sees to be, "Oh, you don't need any keyboard input? Good, I'll let you keep busy, since you seem to be making lots of progress." This is NT doing what it thinks is the right thing -- APPX has done nothing to raise the priority of these processes, or lower the priority of others.) The best thing to do is just be patient.

Some users have reported that it really helps to run on a multi-processor system, so that even if you have one or two of these CPU-hogging processes running, there is still likely to be a CPU which is not as busy.

III. Other NT Operations and Administration Issues

1. Printing to a printer produces blank pages.

Printing to certain printers through winprint.exe can cause the printer to eject lots of blank pages, rather than the desired APPX OUTPUT file. This can be caused by the printer driver not knowing from NT's Forms database the page size of the current form, and returning a form length of zero to winprint.exe.

This can be diagnosed by setting the environment variable WINPRINT_DEBUG=C:\winprint.txt from the DOS command prompt, then manually running winprint against an APPX generated printfile.

To override the NT form length, enter into your APPX FORM table's FORM CONTROL attribute:

-form_id=Letter

A complete list of valid form_ids can be gotten by clicking on winprint.exe from Windows Explorer.

2. File fragmentation.

Extensive file activity can lead to thousands of fragment per file, over time. This cannot help performance and could lead to problems. In lieu of a script to periodically verify and (if no errors found) export and re-import all of the files for all version and application or datbase and application combinations or the pain of full backup and restore, some use Executive Software's DiskKeeper product to do this task, say, after every full nightly backup.

ASI has not tested and in no way warrants this software.

Comments:

Read what other users have said about this page or add your own comments.

-- ChrisBrower - 2011-06-08