I’m using STSDEV 2008 (a utility from Ted Pattison’s group) on a current project to generate the Visual Studio projects for SharePoint deliverables. If you haven’t used it before, I’d recommend checking it out: it offers a pretty nice integrated way to bundle your SharePoint projects into solutions (WSP files).
In any case, I had been very satisfied with how STSDEV was working out until I started getting this message whenever I built the project: "stsdev has stopped working."
Digging in a little, I realized that the utility creates a targets file and some custom build targets that call stsdev after the assembly build to do any necessary packaging, deployment, etc. for the SharePoint solution.
I then did what I often do when an application starts crashing: spun up process monitor to see what resources the application was trying to access.
Turns out STSDEV needs to have write access to three files that it creates in the "DeploymentFiles" folder of the solution: manifest.xml, SolutionConfig.xml, and SolutionPackage.ddf. (Makes sense: these are the files it maintains to build the WSP.)
Then I realized what was up. I had checked all my code into source control, and thus those files were all read-only on disk, and the utility does not overwrite read-only files.
So the takeaway is this: if you’re using STSDEV and your solution is under source control (which it should be!) make sure that you check out the three files mentioned above to allow STSDEV to function correctly.