it will not happen with all maps, and the problem may well happen with other saved games.
It seems to be older maps (?) - and is caused by a probably redundant bit of original SSI code which fixes shell hole numbers. probably from way back in the SP1 to SP2 days, to convert these maps. Unfortunately - it did not do any array bounds checking on the 6 by 6 array of ID numbers it's using so if uninitialised map data goes in, BOOM.
I have added range checking based on the code which actually produces shell holes - and the original code only checked 1 parameter, whereas I am screening 6 or so now to see if the data presented is OK.
I'm also investigating the function's actual relevance - it seems to have become redundant in maybe 1996 or so
!. Simply commenting it out in the load function causes no noticeable problems. So it probably only applied to SP1 maps, or some early version of SP2 methinks to "massage" old-form shell holes and rubble to the new improived model.
meanwhile - the only way to check if the particular custom map is not going to trip this broken function is to set up a quick PBEM with custom map as P1 (any nation pair and just buy a random formation) , load the map, and save as a secure or insecure PBEM. Then load up the saved game as if you were P2. if it loads and does not crash, you will be fine.
I believe this routine probably worked fine in Windows 98 and below (I only have an XP rig on line now, the 98 box is in a cupboard). Unless of course you are trying it in 98?. However - XP seems to be more "picky" about out-of-bounds memory adressing than 98 was.
cheers
Andy