My program which runs fine as a ROM image in blueMSX, crashes when loaded into RAM (on blueMSX and the real thing). I have looked in the blueMSX save state file and it's clear that code is getting overwritten, but I have no idea how. It seems to have something to do with VB interrupts, since disabling ints in certain parts of the code or turning the music player on/off causes it to crash in different places. I don't see how this relates to writing random garbage all over memory

So... is this a penalty for MSXdev?

I would call this behaviour "Konami-style ROM copy protection"

Ouch!, don't get nervous, there's still time to fix it.
I guess that is a standard 16-32K ROM and you're using tools like Execrom to run it on the real thing, isn't it?, apart from that what can you tell us about the main structure of your program?, I mean, how are you using the interrupt service?, are you placing there all the gfx+sound code?, only the sound code?, or maybe are you using HALT to synch part of your program?.
Most probably such erratic behaviour must be produced by an incorrect use of the stack, you must double check all the PUSH/POP pairs as seems that your int could be trashing them. Using the BlueMSX debugger you can also set a breakpoint on the interrupt code and see what happens there.
Tell us more...

The ROM is 48KB. I loaded it with ODO at first, then I made it work as a .COM file also by making it copy itself from $0100 to $0000 and skipping the slots detection. My interrupt routine plays sound and reads the controller status.

Just now I found that replacing some code in the interrupt routine may have fixed it. I had PUSHed ix and iy at the start and POPed them at the end. I changed it so they are saved directly in RAM with a LD ($E03A),ix etc.

Why does that matter? I didn't think there was an SP' shadow register...

No, there's no SP' at all.
So you say that if you save IX and IY registers by hand and not using the stack the whole thing works?, if so I keep thinking that your stack is being corrupted, you must be using IX and/or IY heavily and that's why saving them on another place avoids the crash, the other regs must be also corrupted; but they must be less prone to crash the program. I suposse that you're PUSHing/POPing all the regs (even the shadow regs if you're using them somewhere) in your INT code; but have you defined a safe place for the stack using LD SP,xxxx at the beggining of your program?, are you sure that your data, buffers or whatever are not overwriting your stack?.
I don't have experience with a 48K ROM; but I guess that the game memory map can be a bit more difficult to handle correctly, try to be sure that every thing is placed in its correct place.

oh CRAP!!!!!!!!!11

I thought an interrupt vector went at $0038, when in fact it should be a jp instruction.

Looking forward to see your game! MSXdev'06?

Hehe, seems that you've found something!. Remember that on $38 you must put a JP (it's handy to place your INT code everywhere) OR the full INT code itself. Also, point you that your code (not hooked to $FD9F anymore) will be executed every INT and that period could not be 1/50 sec., if you want to synch with the VBlank to achieve a freq. of 50/60 per sec. you must check first if the INT is a VDP INT as follows:

ISR:		push af
                in a,[$99] ; mandatory!
                bit 7,a
                jr z,@@NOVDP
		push bc
		push de
		push hl
		ex af,af'
		exx
		push af
		push bc
		push de
		push hl
		push ix
		push iy

.....you INT code here

		pop iy
		pop ix
		pop hl
		pop de
		pop bc
		pop af
		exx
		ex af,af'
		pop hl
		pop de
		pop bc
@@NOVDP:        pop af
	        ei
		ret

Just a basic example...