What version of Windows are you using?  I've seen differences in the behavior of the arbiters as Windows has matured.  I don't notice anything incorrect in your ASL.  Does your FUR1 device come up with no conflicts, and only FUR0 has problems?

Are you able to run WinDbg and get the failure?  Depending on the generation, you might have Ethernet or USB available for debug as well, if you need a different option.  I might start with this:
https://msdn.microsoft.com/en-us/library/windows/hardware/ff562124(v=vs.85).aspx

... using "!arbiter 2" to dump the memory assigned in the system.  That would hopefully show you the conflict ('C' flag) and ownership, possibly giving you additional clues and a direction to look.  In theory, this should be somewhat identical to looking at resources-by-connection in the Device Manager, but you'll have more options for debugging.

Maybe also dump the device tree with "!devnode 0 1" and make sure items are scoped where you believe they should be.

The fact that FEDC6000 is used by PCI Bus seems pretty odd, like the bus consumes the memory without bridging or arbitrating it.  Unless I missed it, I don't see anything like that in your DSDT.  As an experiment, maybe try adding a ResourceProducer for FEDC6000 under PCI0 and see if the problem goes away.  If it does, I'll have to think more about what that means.

Thanks,

Marshall