This is a question that personally as a security professional has bugged me for a long time.
So, a default Windows installation, from XP up to 10, typically has a few services listening on the quad-zero (0.0.0.0 for those that might be less familiar with the lingo) for what I'd imagine to be assistance with setup on a domain environment. A lot of these services, like Link-Local Name Resolution or NetBIOS, can be disabled, albeit with a little bit of work.
While I understand that the Windows RPC subsystem has a dependency of nearly every system-installed service, the RPC Endpoint Mapper will bind to the typical msrpc port (port 135) on all interfaces. In a high-security or home environment, listening RPC ports may be undesirable as it may invite potential exploits.
I've messed with some of these facts in a test environment, largely with trying to set the Windows RPC server to listen on the localhost. I've been using RPCCFG, disabling DCOM, the usual steps I find on some dated forums. I know it cannot be disabled entirely, so I've tried to make it at least visible in software under the impression that the functionality would largely remain the same: The mapper is there, just not listening on the hardware. From XP to 10, the only place I've gotten this to work is a Windows Server 2008 R2 Datacenter installation, and I haven't been able to replicate it since.
While I realize in a high-security environment it would be more desirable to just not use Windows with respect to the security concerns, the inability to configure this service and have it work without Windows throwing a CRITICAL_PROCESS_DIED. Call me an enthusiast, but it's always something I've found interesting.
So, can the Windows RPC subsystem listen on localhost without error? Or is it not configurable without breaking all functionality within Windows?