There's another factor that makes me think something went wrong--CM status as of this moment:

Device Discovery 01 Aug 2007, 11:40:14 EDT xxxx Devices Idle Start Device Discovery

where xxxx is over a hundred devices shy of the total number of devices in the DCR.

This is not necessarily a problem. You can add devices to DCR outside of discovery, and Discovery can also use filters to prevent it from counting devices that are in DCR. In order to determine if this is a real problem, you will need to find one device that is in DCR, but missing from Discovery's last sweep, then look through the discovery.log (assuming devdiscovery debugging was enabled) to see why that device might be missing. Look for that device's name and address as well as its neighbors names and addresses.

Device Discovery had always had more devices than what's in DCR (equal to the device number in CM's Data Collection) until this juncture. Most of the extraneous ones found by Device Discovery are "unreachable", and I disabled the Device Discovery=>DCR synchronization. Since I don't have debug on for discovery, should I still bother looking for a device? I did just see the following:

tail -f discovery.log

2007/08/01 11:40:13 EvalTask-Devdiscovery-07 WARNING DevdiscoverySMFGetDeviceType: SNMP unreachable device at: xx.xx.xx.xx will not remap SMFFactory

2007/08/01 11:40:14 main ERROR DevdiscoverySMFEnd: Error in add Device: CSTM Error Code [-23] CSTM Comm Type [0] - Error in reading/Error in received response,, Binary encoding InputStream does not contain a serialized object

2007/08/01 11:40:14 main MESSAGE DiscoveryMain: Properties will be read from /opt/CSCOpx/campus/etc/cwsi/DiscoveryStatus.properties

2007/08/01 11:40:14 main MESSAGE DiscoveryMain: Properties will be read from /opt/CSCOpx/campus/etc/cwsi/DiscoveryStatus.properties

2007/08/01 11:40:14 main MESSAGE DCRDevWrapper: Closing DCRProxy

How did you disable DCR synchronization? The CSTM error here is a problem. This could indicate a problem with DCRServer or with the Campus CTM server (which should be ANIServer). The easiest thing to try to correct this would be a restart of dmgtd.

I stopped the CM=>DCR device sync by deleting the Device Discovery schedule in CM completely.

Bouncing dmgtd is ok for a one-time anomaly, but I'm concerned the same problem might recur. Even though I've disabled Device Discovery and don't need it, I'm uncomfortable with the fact the "ut -cli" export also got affected by this problem--the output of the full ut dump was completely empty.

If you've completely disable Discovery, then the CSTM error may be nothing to worry about. I still don't know what the problem with UT is. So far, you've only talked about Discovery numbers. These have no bearing on what is in User Tracking, and will not affect ut -cli.

Never mind UT. I was looking at the wrong output file. The UT CLI dumps were successful.

Now I believe the Device Discovery that's stuck at 01 Aug 2007, 11:40:14 EDT has nothing to do with UT, but I just find the numbers of Physical and Logial Discrepancies are all zeros, whereas they had been in the thousands normally. Are these related to the CSTM error or Device Discovery (that's been stopped months ago)?

Discrepancies have nothing to do with Discovery, either. Data Collection is solely responsible for detecting discrepancies. If the count suddenly dropped to 0, ANI either found a perfect network, or there was a problem with the last Data Collection. To debug discrepancy problems, enable dcrp debugging under Campus Manager > Admin > Campus Data Collection > Debugging Options, then re-run Campus Data Collection.

Debugging was enabled, but no ani-trace.log was created as a result. I did not enalbe device-level debugging. Data Collection ran as usual, though it took ~34 mins last night compared to the ~25 mins the night before. The discrepancies are back once again. Strange.

Indeed. If dcrp debugging was enabled, you should have seen something in ani.log related to discrepancies.