On Windows Server 2012 R2 systems, we've found some circumstances where the Evolution Request Processor service will stop immediately after starting, with no messages or logs or other clues. We've identified two related causes, and fortunately both are easy to fix.

What's happening is that the Request Processor is talking to the Windows performance counters in order to calculate the RP's score, and the counters in question are either corrupted or have been disabled; when Evolution finds this, it fails in about the least useful way possible.

Cause #1 - Disabled counters due to Windows Update

Windows maintains a large number of performance counters — CPU, disk, network, etc. — and we believe one (as-yet unidentified) Windows Update disables the one that Evolution uses for its score calculation.

We can query the counters from an administrative command window and look for the PerfOS counters:

PS> lodctr /q
Performance Counter ID Queries [PERFLIB]:
    Base Index: 0x00000737 (1847)
    Last Counter Text ID: 0x0000199E (6558)
    Last Help Text ID: 0x0000199F (6559)
...
[PerfNet] Performance Counters (Enabled)
    DLL Name: %SystemRoot%\System32\perfnet.dll
    Open Procedure: OpenNetSvcsObject
    Collect Procedure: CollectNetSvcsObjectData
    Close Procedure: CloseNetSvcsObject

[PerfOS] Performance Counters (Disabled)        ← look at me
    DLL Name: %SystemRoot%\System32\perfos.dll
    Open Procedure: OpenOSObject
    Collect Procedure: CollectOSObjectData
    Close Procedure: CloseOSObject

[PerfProc] Performance Counters (Enabled)
    DLL Name: %SystemRoot%\System32\perfproc.dll
    Open Procedure: OpenSysProcessObject
    Collect Procedure: CollectSysProcessObjectData
    Close Procedure: CloseSysProcessObject

This shows that the key PerfOS has been disabled, and fortunately it's easy to re-enable:

PS> lodctr /e:PerfOS

With the counters enabled, the Evo Request Processor ought to start without incident.

Cause #2 - Changing CPU count in a VM

The performance counter subsystem maintains certain indexes to internal tables, keyed by CPU numbers, and these indexes are built when the operating system is installed. Changing the number of CPUs — most likely in a Virtual Machine environment — means that the prebuilt indexes are invalid, and this breaks the performance counters.

It's also possible that enabling/disabling of HyperThreading can do this, but we've not tried it.

The fix: rebuild the counters. Open an administrat6ive command window and rebuild the counters:

PS> lodctr /r