Although services on Win9x and WinNT are dramatically different in terms of implementation, dnetc attempts to make the behavior between the two environments approximately equal.

In order to reduce its footprint and other overhead, the client runs with an implicit -quiet when started as service, so, even if it did not use the check-for-shell described above, you wouldn't see anything.

Explicitly unencrypting each of the individual files within the directory is not sufficient, since new files created in that directory by the client will inherit the encryption from the parent directory.

Configuring the service to login as me (instead of as LocalSystem) seemed to fix it, but the safer approach is to keep the distributed.net client in an unencrypted directory, where no parent directory is encrypted either.

This limitation will also be apparent if you ever try to encrypt your Windows directory itself, or the base "Documents and Settings" directory (that contains the profile directories for multiple users, not just yourself), or the root directory of a hard drive that contains things that multiple users or the system itself needs to access. Generally speaking, only sensitive documents should be encrypted, and not application directories, or entire hard drives.

Although not specific to NT service, be sure that the interface name that you've told the client to monitor is the correct interface name of your modem connection. However, typing the interface name incorrectly will prevent the client from detecting your modem connection when running as an NT Service or as an interactive process.