=========================================================== Incoming Remote Command Daemon (cwbrxd.exe) Test Fix Readme =========================================================== Note: The information herein applies to both Client Access for Windows 95/NT (both releases 313 and 320) and to the Client Access Express beta. Test fix versions of cwbrxd.exe will be provided for each of these releases. CWBRXD.EXE Versions: Release 313 : 04.001-t1 Release 320 : 05.000-t1 Express beta: 06.000-t1 I. Problem Description and Answer ------------------------------ The following problems seen internally and in some cases externally as well have prompted much investigation into how to either fix or work around these problems that exist when running cwbrxd (either directly, as in Windows 95/98, or as a service, as in Windows NT). For more detail about each solution and how to apply it, see the "Additional Details" section below. 1) Problem: XCOPY sent using RUNRMTCMD to a WinNT PC does not work. Solution/workaround: Use the "/cmddet" option when running XCOPY via RUNRMTCMD to a WinNT PC. 2) Problem: Any command beginning with "start" sent to a WinNT workstation, when a non-Administrator is logged onto that workstation and the userid on RUNRMTCMD is also a non-Administrator, causes a fault. Solution: Use either the "/runassystem" option or the "/cache" option in this scenario. 3) Problem: Memory leaks occur on both Win95/98 and WinNT (cwbrxd uses more and more memory as it runs). Solution: A bug fix and design change have eliminated this in Win 95/98. In Windows NT, use of the "/cache" parameter is most likely required as well. 4) Problem: When many commands are executing at the same time on Win95/98 by cwbrxd, a small percentage of them fail stating that the userid is missing or invalid, when it is really not. Solution: Bug workaround solved the problem, no user action required. 5) Problem: When executing multiple commands simultaneously in Win95/98 using cwbrxd, if one is a console application, the next command does not execute until the console application terminates. Solution: Use either the "/cmddet" option or the "/cmdnewcon" option if any command sent to the PC will run a console application. In summary, fixing or (mostly) working around these problems included some bug fixes, some re-design, and allowing the user to specify various options either for all commands or for a specific command. These are all described below, so read the following to find out more about how to use cwbrxd.exe in a way that will avoid the specific problem(s) you have seen. II. Additional Details ------------------ DESIGN CHANGE: Re-use threads It was discovered that memory is lost each time a thread is created then destroyed. The root cause was not determined; however, the thread-use part of cwbrxd was re-designed such that threads are now re-used, so memory no longer is lost. One result of this is that memory use will increase when a new thread is created, but will not then decrease, since the thread is not ended. However, the number of threads will not exceed the number of commands being run by cwbrxd at once at any given time. USER OPTIONS: How to dispatch the new process to run the command To execute the requested command, cwbrxd dispatches a new process in which the command is run, attempting to capture the output of the new process in order to then send it to the requester. There are multiple ways in which a process can be dispatched; the options made available give the user control over which way is used. Please note that these options are mutually exclusive. When entered as Startup Parameters of the Client Access Remote Command service (in Windows NT), or when running cwbrxd from a DOS command prompt (in Windows 95/98), only the LAST ONE specified will be honored. If more than one are specified as part of the command parameter of RUNRMTCMD, an error will occur. Use one of these options when starting the service or cwbrxd program if you want to set the default for all commands; use one of them at the beginning of the command parameter of RUNRMTCMD if you wish to override the default for that single command. If none of the below options are specified, the method used is as follows: * Client Access for Windows 95/NT: /cmdnorm * Client Access Express beta: /cmdnewcon OPTION: run the command in a detached process ("/cmddet") The XCOPY.EXE program on Windows NT, for unknown reasons, will simply exit without message when run using cwbrxd, UNLESS the process created to run XCOPY is created as a detached process. To run the command in a detached process, use the "/cmddet" option. Unfortunately, a detached process, when running a program (rather than a built-in command such as "dir"), has all ties to the main process broken, one effect of which is to break the mechanism by which the command output is captured to send back to the host. Thus, when a program is run detached, the output in the spool file will state that the command produced no output, even though the command itself probably ran normally. Because of this drawback, you may wish to use this option only for those commands that will not work unless the process is run detached. Currently, XCOPY is the only such program that we know of, but there may be others. OPTION: run the command in a new console ("/cmdnewcon") A problem with concurrently running multiple commands using cwbrxd was discovered, where when a console application, such as EDIT.EXE, is run, other commands sent to the PC using RUNRMTCMD are not run until the console application on the PC is ended. Although cwbrxd is designed primarily for running non-interactive commands, it is allowable to run interactive ones, including console applications that are long-running or where user interaction is required to end the application. To work around the problem described above, a new user-specifiable option, "/cmdnewcon", is provided. When this option is specified, the command sent will be run in a newly-created console rather than in the console cwbrxd itself is running in, and will not cause other commands to wait. OPTION: run the command the "normal" way ("/cmdnorm") When this option is specified, the process to run the command is neither detached, nor does it get its own new console in which to run the command. You may find this to be the best option for running certain commands, depending on the behavior desired. USER OPTION: run in the system context ("/runassystem") The case where a command beginning with "start" would fault on WinNT has something to do with the lack of authority of the user the command is run in the context of. Therefore, if the command is NOT run in the context of the user passed on RUNRMTCMD, but rather in the System context, the fault should not occur, and this has proven to be the case. The command appears to run successfully, and the output is captured as it normally would be. This option can be specified only as a Startup Parameter for the Client Access Remote Command service. The side-effects that this option causes are unknown at this time; further investigation is pending. USER OPTION: cache security info ("/cache") To work around an apparent memory leak problem with password validation on NT, caching of all valid userid/password pairs was implemented. When a userid specified on RUNRMTCMD has not yet been validated by cwbrxd during its current run, the appropriate calls are made to validate the sent userid and password on the NT PC. If this succeeds, the userid and password are cached (saved), so that the next time this userid is specified on a RUNRMTCMD to the same PC, the password is simply checked against the cached one, rather than calling an NT API to validate them. The disadvantage to using this option is that the password for a userid can be changed, or the userid itself removed from the valid user list for the WinNT PC, without cwbrxd knowing about it. The means that it is possibile that a userid and password that are NOT currently valid can be used to execute remote commands on that PC. The cache can be cleared only by stopping and re-starting the Client Access Remote Command service. This option, "/cache", can be specified only as a Startup Parameter of the service when started. Since the NT API for validation is not called each time, commands must be run in the System context. This means that use of the "/cache" option implies use of the "/runassystem" option as well, and that all side-effects of using this option are not yet known. III. Install/Uninstall ----------------- Cwbrxd.exe is stored in the directory in which Windows is installed. To install this test fix, perform the following steps: 1) Make sure cwbrxd.exe is not running, or for Windows NT, that the Client Access Remote Command service is stopped. 2) Go to the Windows install directory, e.g. C:\>cd windows 3) Backup the current version of cwbrxd.exe, e.g. C:\windows\>copy cwbrxd.exe cwbrxd.bak 4) Copy the new version as cwbrxd.exe, e.g. C:\windows\>copy cwbrxd.tf1 cwbrxd.exe To uninstall the test fix, perform the following steps: 1) Make sure cwbrxd.exe is not running, or for Windows NT, that the Client Access Remote Command service is stopped. 2) Go to the Windows install directory, e.g. C:\>cd windows 3) Restore the backed-up version of cwbrxd.exe, e.g. C:\windows\>copy cwbrxd.bak cwbrxd.exe