Oh man, I've definitely been there myself. Maybe you even saw my "Schroedinbug / LD03 error" story I posted back in July in my game journal thread. It never fails to be discouraging. If I ever hit that point where I feel like throwing it out and calling it a day (so you're not alone there), that means a nice vacation is in order. No problem is impossible to solve, but sometimes it takes a few days break to remember that.
Crashes are actually a
good result of a bug, because with the right tools you can then analyze where things went wrong. I didn't know about what Luyren advised, but it's useful to know. Since I develop on Linux, I usually use gdb instead.
The worst kinds of bugs are the ones like the sound, since they leave less of a foot print. The one thing that's absolutely saved me countless times in my game is my error reporting system. It's probably the most important feature of the game engine. I've posted a few screenshots of them from time to time. They usually post a four symbol error code.
What you don't see is the mountain of info that's dumped to the log file-spitting out any data that I thought might even be remotely relevant. It's my version of
assertion.
My advice to anyone working on large scale projects is to invest some time predicting all the things that can go wrong and checking for them in each critical function/script you write. The extra time spent doing this early on will pay off in improved sanity later

I have
683 error checks right now. Some are intended to catch things like damaged files, modders who want to tinker with the maps, that sort of thing--but the vast majority of them are intended to catch my own mistakes... say, if I forget some criteria for a certain method to work correctly.
For example, if I want to make a new kind of tile, there are several things I have to set for it to work correctly. If I forget a step, the game will run, but maybe there will be a clipping error, or the tiles draw out of order. Without some assistance, there are dozens of places to look for a problem. Is there some numerical round off error? A memory issue? Did I just draw the image wrong?
In your case, maybe you have a behavior "A" that loads an actor in an "on created" event, then another behavior "B" reads that attribute in its "on created" event. It works fine, but then for some reason, two years later, the order the behaviors are loaded changes, and suddenly behavior "B" tries to read the actor attribute before "A" creates it. If you have a check in behavior "B" for a null value, then you get an error message telling you exactly what went wrong. Otherwise, you have a crash, and two year's worth of code to look through to find it.
I will second Luyren's advice on inverting your workflow. Flash is not as rigorous as desktop. It'll let you get away with some null values that desktop won't. By testing on desktop more frequently, you're likely to catch these kinds of errors earlier, when there's less work to sift through when the problem occurs.