I do QA on a large commercial code, this irritating scenario does come up way too often. Usually it is indicative of not having ironclad proceedures for building the binary on all the platforms we support. So if the developer builds his own code (which he has to do to debug and fix), and doesn't follow the same build proceedure to the letter, there is a chance that system dependent bugs will appear to magically vanish (or appear). Of course these things usually get closed with "works for me" in the bug database, and if they fail the next time that problem is run, the bug can be re-opened. Whenever I suspect a bug may be system dependent, I try to test it on a variety of platforms and report under which conditions it happens. Oftentimes a memory corruption issue onlt shows up if the corrupted data is of large enough magnitude to cause a crash. Some platforms (HW and OS combinations) may crash closer to the actual source of the corruption, and this can be very valuable for the poor guy that has to debug it.
The tester needs to do some value added, beyond just reporting that his system shows a failure. I spend a lot of time screening out false positives -maybe the platform in question was overloaded, or the network had a glitch. And yes sometimes you can get something that is truly affected by random timing events, hardware bugs can often be like proto example: If
two data requests come back a exactly the same clock period, and the hardware logic for handling the potential conflict is faulty, then the bug will only show up intermittently. Likewise with parallel processing, unless by careful design you've constrained the solution to be independent of which processor happened to be faster, you can get bugs that only happen once in a blue moon, and their statistical imporbablity makes debugging a nightmare.
Also our code is being updated, usually many times daily, tracking down an exact sourcecode revision number for when it went south can be very useful information for the debugging effort. The tester shouldn't be in an adversarial relationship with the debuggers and developers, he is there as part of a team to improve the quality of the product.