I have a C# app using SqlCe that I can’t always attach to after deploying my solution to the emulator which does imply I can attach sometimes. I can sometimes redeploy multiple times before this issue starts showing and other times I have the issue on first startup of application.
I don’t have a real pocket PC yet so don’t know if this reproduces there. And I have not tried this on the 1.0 version of the emulator as of yet. The error I receive is “Unable to attach to the process. Operation not supported. Unknown error: 0xc0000005.” This crashes the process on the emulator.
Any advice would be great.
Environment:
Visual Studio 2005
Pocket PC 2003 SE Emulator Second Edition virtual machine
Active sync 4.1 being used for network connection
What seems to fix it for a while:
Once I start getting this error the only way I have been able to attach to my application is to Stop the application (settings > system > memory > stop); uncradle in device manager; exit and save settings on emulated device; connect to device with device manager; cradle device with device manager; start my application and attach to process with visual studio.
What things I have tried that does not work:
- Closing and reopening VS 2005
- Uncradle and Cradle emulated device
- Manually copy new assemblies to emulated device instead of using deploy feature in VS
- Exit and save state on device without uncradle
- Exit and don’t save state on device without uncradle
- Stopping the application with the debugger attached
Error attaching to process on Microsoft Device Emulator 2.0 beta with VS 2005
djjdaeja
I will be on vacation for this upcoming week so if anything comes up I'll respond as soon as I return. Thanks again,
-Noah Falk
.Net Compact Framework
waddies
OK - that banner message says FsaMobile.exe crashed. If that is your app, that's your problem: the managed attach cannot take place in a crashed process.
Barry
RichLeyshon
Jason, I just moved your post over to the .NETCF forum - it is possible that the crash is happening inside the .NETCF runtime during process attach.
Barry
nzmike
Sure thing, here you go.
Data Abort: Thread=9665823c Proc=8c247a60 'FsaMobile.exe'
AKY=00100001 PC=03fad698 RA=017f4a64 BVA=2a000000 FSR=00000407
GTrz
Could you open the emulator's console window before trying to attach to your application Use file/configure and in the Peripherals tab, check the "Create text console window for serial port 1" checkbox.
When the crash happens, the CE kernel should print some diagnostic information to that console window. Can you post it to this forum thread
Thanks,
Barry
pixel8r
TKwin
I am back
-Noah Falk
.Net Compact Framework
roadresident
Sorry was on vacation and then a business trip.
Since posting I got a real device, but would love to be of help here. What can I do to assist in figuring out what is going on
Bastiaan Molsbeck
Jason,
Barry just forwarded this along. It looks like this has been idle for quite a while now but if you are still monitoring the thread just reply back and let me know. I would be happy to help investigate the crash.
-Noah Falk
.Net Compact Framework
r3n
I think best shot at this point is to get a native debugger attached when the app crashes and hope we can get a little more information about what has happened. Lets try using the native JIT debugging which you can set up like this:
- Go to <VS Install Directory>\SmartDevices\Debugger\target\wce400\cpu\armv4 - Copy eDbgJit.exe to the \windows folder on the device.
- Soft Reset the emulator
Assume now you have started a native application on the device and then it crashes for some reason. Then you would be prompted with a dialog whose contents should look like
An unhandled exception
was raised in "exe path +name"
(process id = xxxxxx)
To debug attach with
Visual Studio
To terminate, click OK.
You may want to write a tiny native app with VS that immediately derefences null, divides by zero, or causes your favorite native exception just to verify that jit debugging is working properly and you can attach the VS native debugger when the dialog pops up.
Once everything looks to be working properly you can try to repro your crash and then hook up the native debugger. Without symbols this is going to look fairly cryptic I think, but you can just grab some screenshots of the stack trace window for the various threads, the threads window, and the modules window (make sure to get address ranges where the modules are loaded on the screen).
Let me know how that goes and if succesful you can send screenshots to me at noahfalk AT microsoft DOT com. Thanks,
-Noah Falk
.Net Compact Framework
Robert F Pickering