Yeah, these kinds of issue, such things as this do appear to cause instability for me too.
I've removed all M4L devices from my default set as a result...
I've aggressively disabled a lot of Windows features - from a Windows perspective, I run a tight ship. And before I start Ableton, I kill yet more apps in a batch script (dropbox, nvidia control panel app, others), and even disable my Network Card (a wired ethernet card). The more you can stop before launching Ableton with M4L, the better it seems. I'm not exactly sure which one / combination gives me apparently a more robust system, and it'd be a long-winded trial-and-error process to find that, so I just stop as much as I can get away with.
My current startup process for Ableton (which seems to be giving me most stability) is to first add the Max Midi Effect to my default set (having native ableton devices and vsts in the default set seems OK), leave it load in full (give it two mins or so, until the disk sounds less busy), and clicking on the Edit button to present the Max Editor for that patcher. Feel like that little tap-dance forces Ableton/Windows load Cycling74 runtime dependencies in order, and allows memory to be allocated without interruption from separate events, reducing the effort of library load synchronization, or whatever...
On Win7 32-bit, with the 3GB support flag set, I can now run an Ableton processs at 2.5 Gig set without choking, even at 128 samples into a Scarlett 6i6. That's loading two instances of Sonic Faction Sickness and Sonic Faction Hatchet (both sample-heavy M4L devices), a couple of other smaller Max devices, and some vsts and native devices.
(FYI, here's the page I used to switch on 3GB support for user processes: http://knowledge.autodesk.com/support/a ... -XP-s.html
Oscillot still is a problem, and it seems that presenting the module patch editor dialog is what hurts me most reliably. The effect for me is that it causes the 'freeze' / 99% CPU issue I mentioned above - Ableton spikes to 99% CPU, audio stops, mouse moves slow, computer is too busy with Ableton to do anything much else: that lasts for a 10-20 seconds, then CPU usage drops down to normal levels again, and Ableton is fine; and maybe a minute or so later, it spikes up to 99% again - once that happens once in a Set, it'll keep happening - I've no choice by to close Ableton. But at least Ableton is still usable (I can save) in between CPU spikes.
Also, it appears that when I drag and drop devices into slots, I'm more likely to cause the CPU Spikes scenario.
So, in summary, it seems that killing as much as possible, and giving Ableton breathing space to load stuff 'in its own time', helps m4l stability. And there seems to be some kind of CPU Spike issue, maybe associated with screen redaws, for me at least.