[ Warning excessive nerdiness follows. ] Since you're curious, Garmin's GGZ and observation of the units behaviour offers a pretty good hint on why this has been a problem with dozens of Garmin models. I've not reverse engineered them to confirm this and I could be wrong, but I have a bit of relevant engineering experience here.   If you add a big GPX file and boot, you'll notice it takes a long time. Some combination of the XML parsing and putting into the unit's internal (probably sqlite3) database is slow. Really slow. Slow enough we want to avoid it when we can. We'll come back to this in a moment.   There's a bounded amount of flash storage inside the device. Garmin never says what it is (the flash chips are probably the most readily identifiable to someone willing to void a warranty) but we can be pretty sure it's WAY smaller than a typical uSD card. This is why every unit has a max.   There are also parts of that GPX file that they NEED to be fast (lat/lon, cache type, container side) that are pretty small and some parts that can be large (I think a cache description can be 50K on Groundspeak but not formally bounded by size and logs are technically unbounded by number, even though there's probably a limit on log length.) You don't NEED the cache description and logs until you're actually viewing the cache page. So based on that limited internal space, it's quite likely that the device stores that stuff it needs to be fast internally and puts indices/pointers (think post-it notes or lines) onto the SD card. (Think of it like the valet getting stuff from long-term parking.) So there's a line that says "For GC1234, the data is in MyTrip.gpx and the description starts at file offset 64,536 and ends and 65,431. So the internal stuff is fast and only when we're going to actually view the full stuff do we have to send the valet to get the slow/long information, but that's OK because the valet's little drawer of keys knows that parking ticket number GC1234, came from the garage MyTrip.gpx, and is in stall 765.   Now let's come back to that slow boot thing. Doing that all the time on every boot is not very awesome. Garmin eventually noticed, "Oh, I've seen this GPX before, I can skip the read." It's actually little bit harder than that. You can't always skip it, the contents might have changed. So if the timestamp on MyTrip.gpx changed, we just have to nuke everything that came from MyTrip.gpx and read that. That's why you see the slow boot in this case. (This is also why the general "take two aspirin" advice of "remove everything, boot, put everything back, boot" is solid advice.) This kind of hints that the speed problem is in their XML reader; if the database write was the bottleneck, they're probably just always read them and do 'replace into' which wouldn't change the record if not changed.   Now, what happens if you have multiple files with overlapping geocaches on the device? Let's say GC1234 was in MyTrip.gpx AND in Winter.gpx. Which one "wins"? What if the internal database and the card contents get out of sync? Maybe the device crashed or batteries ran out or some programmer missed a 'transaction begin' or such. Now, the parking voucher that says it's in stall 765 may get confused because stall 765 is in a file that's been removed or there's a totally different type of car there so the beginning and ending pointers now point to nonsense. What if the programmers didn't handle some error case, such as the start and end XML tags actually being start and end XML tags? What if I copied the original on a computer that has an accurate clock, and later that has a date in the past: the date didn't move forward - does it do a re-read or not? In any of these cases (and probably more than I'm not coming up with right now.) the device will PROBABLY do something bad. That might be showing nothing, showing jibberish, or crashing: I've seen all three. This would happen exactly when you go from an overview (picking an entry from the map) to the detailed page to get the relatively large stuff, such as to get the hint or description. That's the majority of the time mine will crash a few times a day when I'm power-caching. This is also why I keep my geocaches on the SD card - if the unit loses its mind and I have to do it in the field, I can take the card out, fast boot, put the card back in, slow boot, and probably be OK for the remainder of the day.   You can see Garmin tried to address some of this in the GGZ format[1]. They split the fast data out into what's little more than a .loc file with the kind of pointers I've described. They also added a tag inside the file that contains the CRC of the related pieces so they can see if something has changed without needing to read it all. I created a GGZ writer for GPSBabel (that I rolled back because I broke GPX in the process and general lack of interest in GPSBabel community in GGZ) that bozoed the pointers that came in any caches logically after any multi-byte character. So my original test case of all US text worked great, but the moment I fed it even European caches, it pretty much fell flat on its face. The symptoms were exactly that: the overview worked, but the GPS crashed when you opened the caches AFTER those.   There's a bit of poetry here that what I've described above is "caching". (Remember, that word means putting something away for future use: hikers may do it for food, military may do it with gear, computer nerds may do it for performance.) So that's probably called a "cache cache". There is an old comp sci adage that "There are only two hard things in Computer Science: cache invalidation and naming things" so that plays nicely into both. :-)   In case I need disclosure, I have no inside knowledge on WHY these Garmins crash show much, but I have developed several similar systems and that would neatly explain the observed behaviour like crazy HTML no longer being the smoking gun that it was in the Colorado era as well as why remove/boot/add back is the "cure" and why it's hard to reproduce. I could be wrong.   Oh, and as a minor aside to Red90: thank you for your ongoing service in this group, and I hate to be picky, but to computer people a Mac and a MAC are different things. The first is a computer-like substance built by a company in Cupertino. The second is an acronym for Media Access Control, one of the lower levels of the OSI stack as used by 802 (Wifi, Ethernet) and even cellular radios. So a Mac frequently has multiple MACs.   [1] GGZ is pretty bulletproof within a single GGZ, but I'd bet that multiple caches coming and going between multiple GGZs could probably trigger similar naughtiness. You're just less likely to trigger this because "everything in one honking huge GGZ" is probably a more common model than multiple GPXes.