I'm sure this used to work before my machine crashed a while ago. I'm using VC++ 6.0 and when I try to start HouseBotServer.exe as part of a debugging session I get an access violation. If I just execute it by hitting Ctrl+F5 everything runs as it should except of course no debugging.
Sometimes when you mix release/debug modules, I've seen that too. I realize that you can't really do much with the fact that the EXE is built in release.
Can you give me a stack trace where it crashes, or a fault address?
I tried the sample device that comes in the SDK and it didn't work either. HouseBotServer.exe seems to crash before it even gets started good, no splash screen or any sign that the app has started ever shows up.
One thing I that happened that I don't think is related is that when I tried to compile the sample I got an error about free and malloc being undefined so I had to include <stdlib.h> in stdafx.h to get it to compile.
It definitely sounds like a difference between our build environments. The free and malloc errors may be indicative of the problem. Make sure you've upgraded VC all the way to SP6.
Maybe try including <malloc.h> instead of <stdlib.h> ???
How are you including definitions for free and malloc? Wen you compile the sample using the included project file do you not get the errors about free and malloc?
EDIT I just looked and SP6 only deals with Visual SourceSafe.
I tried including <malloc.h> and got the same crash.
I can attach to the already running HouseBotServer.exe process and do some of the debugging but that is a pain and I don't get to debug the initial startup sequence without some trickery.
It's probably something in my include path that is different from yours. I'm including in some ATL paths that may make a difference.
Now that I look at the paths, they don't seem like the most obvious, but I'm sure I tweaked them that way over time (not just for HouseBot). The paths in order go like this:
Since I'm all out of ideas I guess I'm stuck with attaching to the process to do any debugging for now. I don't want to waste more time trying to figure it out, I would rather just be productive on my plug-ins.
Well the next build will not be done on my machine, so maybe the problem will go away with the next release, since it will have a somewhat different build environment.