Troubleshooting

WinAppxD was replaced by the APPX Login Manager in Release 5.0.0. See this page for installing & configuring the Login Manager.

6.1) WinAppxD service is not running

First, login as Administrator and check Event Viewer, to see if there are any errors regarding SRVANY.EXE startup. These could occur if the WinAppxD service registry entry points to the wrong pathname for the winappxd.exe executable. If you see errors, edit the appropriate registry key to fix the path name or command syntax. (See WinAppxD installation instructions for registry locations to check.)

If there are no SRVANY.EXE errors saying that the service failed to start, then WinAppxD started executing, but some type of error caused it to exit.

Instruct WinAppxD to create a log file by defining the following environment variables:

APPX_NET_LOG=c:\appxdlog.txt APPX_NET_LOG_MASK=0xFFFFFFFF

(Set these using Control Panel, in the same global System area you set the other APPX variables.)

Reboot.

Wait a few minutes to make sure WinAppxD has had a chance to start.

Check the c:\appxdlog.txt file for error messages.

IF NO LOG FILE EXISTS, check to make sure that the logging variables APPX_NET_LOG and APPX_NET_LOG_MASK are still defined, and that they were defined in the global System environment area, not the user-specific area. (A common error.) If they appear to be defined correctly, then it is extremely likely that the environment variable "APPX_SERVER" is not set, because some versions of WinAppxD will exit silently, with no error indication, if APPX_SERVER is not set. Another possibility is that the Windows "winsock" library could not be correctly initialized, but this is unlikely if you have TCP/IP installed.

Some error messages you might see in the log are:

"Allocation of TOKEN_USER failed" - This is a system error which should never occur. It is indicative of the system having trouble allocating memory to hold a data structure. - Resolution: Reboot and try again. If it still fails, call APPX Software Technical Support.

"LookupAccountSid() failed" - This is a system error which should never occur. It says that NT could not retrieve security information for the account used to run WinAppxD. - Resolution: Reboot and try again. If it still fails, call APPX Software Technical Support.

"can't open stream socket" - This is a system error which should never occur. - Resolution: Reboot and try again. If it still fails, call APPX Software Technical Support.

"can't bind local address" - Something on your server already has the port you specified in the "-s=" argument, open. Causes:

1. A lingering copy of WinAppxD. Check to make sure no copies of WinAppxD are listed in Task Manager. This may occur if you Start and Stop the WinAppxD service using Control Panel, or if you run WinAppxD from the command line during troubleshooting. If you see any rogue WinAppxD's, kill them and try again. 2. Some other (non-APPX) application wants to use the port you specified in the "-s=" argument for WinAppxD during installation. There is no completely reliable way to detect this. If you are getting the "can't bind" error and are sure it's not due to an extra WinAppxD process running, this is probably what has happened. Since WinAppxD can't use a port claimed by another application, go back and edit the registry, choosing a different port number for the WinAppxD service. For example, try 8061 instead of 8060. Reboot, and try again.

- Resolution: If you've tried the above and it still isn't working, call APPX Software Technical Support. "accept error - {n}" - This is a system error which should never occur. - Resolution: record what {n} is, and call APPX Software Technical Support for assistance.

6.2 Client login issues - Incorrect login

If you are receiving the error "Incorrect login" when trying to login to APPX from a client PC, there are several common reasons for it.

The best diagnostic information is available in server-side logs, not client-side, since generally these failures occur as a result of a Windows function call failing inside winappxd. Here's how to collect a server-side log to find out more about a WinAppxD error.

Procedure for current WinAppxD, through 3.2.x:

Set the following vaariables in the same place you set APPX_SERVER:

APPX_NET_LOG=c:\appxserv.log APPX_NET_LOG_MASK=0xFFFFFFFF

Reboot.

If you are attempting to login from the console of the APPX server, you must use a command prompt to reset APPX_NET_LOG then run "appx -c". It is necessary to do this, because if you don't reset APPX_NET_LOG, the (probably uninteresting) client log will overwrite the (probably very interesting) server-side log. Start up a DOS command shell, then type:

set APPX_NET_LOG=c:\appxcli.log now cd to your directory containing appx.exe appx -c

Otherwise, if you are attempting to login from a different PC, you can either set APPX_NET_LOG and APPX_NET_LOG_MASK in your global System variables via Control Panel / System / User Environment (or for Win95, set them in AUTOEXEC.BAT) then reboot and run the APPX client, OR (probably quicker) do the following from a DOS command shell on the client:

set APPX_NET_LOG=c:\appxcli.log set APPX_NET_LOG_MASK=0xFFFFFFFF now cd to your directory containing appx.exe appx -c Now check the contents of c:\appxserv.log on the server. A ways down in the file, you should find a line that looks like:

LogonUser() failed with 9999

In place of the 9999, you will see a number which is the reason Windows NT denied the login request. Common ones we've seen, and what to do to solve the problem they indicate, are:

1314. This indicates that the account used to run WinAppxD is missing one or more of the 4 user user rights it needs. See sections 1.6 and 1.7 (or the WinAppxD installation instructions) for details on setting these rights. Generally "Replace a process level token" or "Act as part of the operating system" is the right that is missing (others may be as well).

1326. This is Windows error "ERROR LOGON FAILURE" which might mean that the user ID is unknown to NT, or that the password specified during APPX client login is incorrect. However, it is MUCH more likely to mean that the account used to run WinAppxD does not have the 4 rights set, that it needs to have set (or that you set them on the PDC instead of the local server). See sections 1.6 and 1.7 (or the WinAppxD installation instructions) for details on setting these rights. Generally "Log on as a service" is the right that is missing (others may be as well). You can verify it's not a user/password error by logging in to the user from the server's console. It MAY also mean that you have started WinAppxD from the Local SYSTEM account. Check your Services control panel applet entry for WinAppxD to make sure you have specified a user ID and password, rather than trying to run it under the SYTEM account. If your LogonUser(….) line in your NET LOG (see above instructions about how to create one) lists "NTAUTHORITY", this is almost certainly the problem, as that is the pseudo-domain membership of the Local SYSTEM account.

1385. The user you're trying to login with from the client, does not have the right to logon locally to the server machine. Set this right from User Manager on your APPX Server (make sure to choose the machine name rather than the domain name when you start User Manager). Rather than setting this for each user individually, you probably want to set it for "Domain Users" or "Everyone", or better, a group called something like "APPX Users" which contains only those users allowed to run APPX. See section 1.18 for more information.

If you have a different return code than the above, if you don't have a "LogonUser() failed" line in your log file at all, or if you have one of the codes above but the recommended solution is not working for you, please call APPX Software Technical Support.

When calling APPX Software Technical Support, there are several pieces of information you can have ready that are likely to speed up the problem-solving process for an "Incorrect login" error:

a. What the "LogonUser() failed" return code is. B. Whether you were trying to connect to the server from the server itself, or from a separate client PC. C. Whether "appx -c" logins from OTHER machines work. D. Whether the user you're trying to login with is in the Administrators group on the server. E. Whether "appx -c" logins using OTHER user ID's (Administrator and other non-privileged users) work. Once you have successfully connected to APPX with your clients, remember to remove the APPX_NET_LOG and APPX_NET_LOG_MASK variables from Control Panel / System / User Environment (or your AUTOEXEC.BAT for Win95 clients).

6.3 HASP not seen by APPX

If the APPX Registration screen shows your serial number as "00-…", then it is not seeing the HASP. As of APPX 3.3 and beyond, APPX should produce a CASSERT describing the problem. You may be able to figure out what to do to fix it, from the message. If not, call APPX Software Technical Support. This message will not necessarily appear if you are running the "appx -c" client, therefore we recommend that while troubleshooting HASP issues, you run APPX directly on the server.

If you are running a version prior to 3.3, you will need to collect a debug log on the server. You may also need to do this when running a later version, if APPX Software Technical Support requests it. Here's how to do it.

Set the following variables in the same place you set APPX_SERVER:

APPX_SS_LOG=c:\hasplog.txt APPX_SS_CODE=0xFFFFFFFF

Reboot again, then run APPX directly on the server once more. You will probably be presented with the Registration screen and some sort of license error again. Exit APPX. Now go look at c:\hasplog.txt.

If the problem and its resolution are not obvious, call APPX Software Technical Support for assistance. We will need to see (email is best) or hear (over the phone) the contents of the debug log.

Remember to remove the APPX_SS_LOG and APX_SS_CODE variables once the HASP is successfully recognized!

6.4 Winprint won't print to my printer

Using Control Panel / System / User Environment, set a global system environment variable WINPRINT_DEBUG on the machine running WinAppxD to the name of a file in a directory which is writable by everyone.

Reboot the machine.

Try to print again. Then, look in the log file to see what it says. There might be an obvious failure, like it truncated your printer name (if it was a really long printer name), or it substituted an underscore for a space, or some such. If the failure is not obvious, contact APPX Software Technical Support. We will probably want to see (via email) or hear (over the phone) the contents of the log file.

Remember to remove the WINPRINT_DEBUG variable once you have solved the printing error.

6.5 Winprint won't print to printers that are not defined on my NT server

As of version 3.5 and earlier, APPX can only print to printers which the server knows about, because the printing task occurs on the server.

This means that if a user wants their report to come out on their local printer, there are two options that we currently know of:

A. Define the printer on the server, and map it to that user's printer. This is the preferred method, in terms of being easy for the user. However, it may be difficult or impossible for a particular site to keep these definitions up to date.

B. Have the user email (using OPT-7) the report to themselves, and print it from email. See section 4.1 for how to do this. The caveat here is that if it's a big report, it's going to take up lots of space on your mail server.

We understand that many sites consider this an inconvenience and expect to implement client-side printing in a future release, to more easily allow this to be done.

6.6 Getting an APPX Stack Trace / Disabling Dr. Watson

If APPX is ending with an error, then it is helpful to the APPX Tech Support staff if you can collect an APPX Stack Trace and email it to us along with the rest of the information we request.

You don't have to do anything to APPX itself to cause it to create the "appx.stk" text file containing the stack trace. However, you do have to disable Dr. Watson. If you do not disable Dr. Watson, then an APPX error will invoke Dr. Watson rather than the APPX Stack Trace recorder. To disable Dr. Watson, go into your NT system32 directory, and look for the file named drwtsn32.exe, and rename that file to drwtsn32.disabled. You might have to reboot after doing this, in order to get APPX to generate the stack trace. After you've gotten the stack trace info, you might want to rename drwtsn32.disabled back to drwtsn32.exe so that your next non-APPX error will be handled by it.

6.7 "Can't connect to Host" or "Connection refused by host".

If, when attempting to connect from the Windows or Java clients, you get either of the above two messages, the Presentation Server is probably not running.

For an NT based Presentation Server, see section 6.1 above for debugging approaches. Also for NT Presentation Server: 1) Bring up the Task Manager and look for a WinAppxD process, which should tell us whether WinAppxD is running. 2) Running "netstat -a" and looking for "*.8060" (for example) in the "Local Address" list will tell you if anything is listening on the port. For example: C:\WINDOWS> netstat -a Active Connections Proto Local Address Foreign Address State TCP oz:1079 P66:0 LISTENING TCP oz:1650 P66:0 LISTENING TCP oz:1656 P66:0 LISTENING TCP oz:1533 P66:0 LISTENING

Services for WinAppxD has a radio button giving alternatives for 'System' or 'This Account:'. The latter should be on, with UserID equal to the APPX user set up for this Presentation Server. Try reentering the password for this User Account. Then Re-IPL.

For a Unix based Presentation Server:

To see what Presentation Servers are running, execute: ps -ef | grep appxd To see what ports (prefixed with '806') are being listened to: netstat -a | grep 806 Proto Recv-Q Send-Q Local Address Foreign Address (state) tcp 0 0 .8064 *. LISTEN tcp 0 0 .8068 *. LISTEN tcp 0 0 .8067 *. LISTEN See also ECRs #4725 and #4731.

6.8 "I connect to my customer over the internet, running APPX on their NT. It works okay, but once in a while my APPX session just dies on my laptop. I guess it is timing out, or something. "Although I can start another APPX session and continue working, the previous session is still running on the NT and has the process locked that I want to work on. What can I do to free up that process, given that I am running over the internet?" ==> Write down the PID that appears on your APPX/Client screen before it dies. Next time you log on you could issue to the APPX/Server a RUN to the O/S that executes a 'kill' on that PID. (Note that your kill will only kill a process with that PID, that is also owned by you as the UID.) From the Microsoft documentation, the format is: kill <process id> … or … kill -f <process id> # Anyone know what the -f does? (The 'kill' command is not part of Windows 2000. A shareware replacement, 'pskill', is available at: http://www.sysinternals.com/ntw2k/freeware/pskill.shtml )

If you go into Registration Usage at 3)SysAdmin, 1)Setup, 1)Registration, 2)View Registration Usage, you can see the PIDs of registrations in use.

If Registration Usage contains entries for which there is no corresponding entry in the Task Manager's Processes list, you may want to set environment variable APPX_LS_GHOSTS=1, in order to instruct APPX to purge the dead entries. And/or delete $APPXPATH/0SA/Data/USAGE.dat and USAGE.key at will.

Comments:

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