Subject: Reproducible crash (0xc0000005) in PHD2 during camera looping with custom Alpaca camera server

[myk...@gmail.com]

PHD2 version: 2.6.14 (confirmed up-to-date via in-app updater)
OS: Windows 11
Camera connection: ASCOM.AlpacaDynamic1.Camera (Alpaca), device name shown as "IDS Custom Camera (ASCOM)"

Summary:
PHD2 crashes with a hard access violation every time I click "Loop" against my Alpaca-compliant camera server, regardless of exposure duration, subframe size, or image data returned. The crash happens at the identical fault offset across multiple independent, substantially different backend implementations I've tested against, which points to something in PHD2's own exposure-handling code rather than anything specific to my server's responses.

Steps to reproduce:

1. Connect PHD2 to a custom Alpaca Camera device (via the ASCOM Alpaca dynamic driver / Discovery chooser).
2. Connect successfully -- camera connects cleanly, properties read without error.
3. Click "Loop" to start continuous exposures (tested at 500ms duration).
4. The first exposure is scheduled and starts processing (debug log shows: "Handling exposure in thread, d=500 o=3 r=(0,0,0,0)").
5. PHD2 crashes hard immediately after -- no further debug log lines are written, and Windows Event Viewer logs an Application Error for phd2.exe itself.

Crash evidence (Windows Event Viewer, Event ID 1000):
Faulting application name: phd2.exe, version 0.0.0.0
Faulting module name: phd2.exe (crashes in its own code, not a third-party DLL)
Exception code: 0xc0000005 (access violation)
Fault offset: 0x000649e8

This exact fault offset (0x000649e8) has now shown up identically across at least three separate test sessions, including after I substantially rewrote my server's response handling (changing JSON field structure, image array orientation, and internal exposure-scheduling logic) -- the crash location in phd2.exe never moved, which strongly suggests the bug is in PHD2's own exposure-processing code, not something triggerable only by a specific malformed response.

One consistent oddity noted in the debug log across every session: immediately after connecting, PHD2 logs "FrameSize=(0,0)" even though my server's CameraXSize/CameraYSize endpoints return correct nonzero values (confirmed via direct HTTP log inspection on my end, showing clean 200 OK responses with correct data at the exact moment PHD2 queried them). This might be unrelated to the crash, or might be a contributing factor -- flagging it in case it's useful.

I have multiple full debug logs from repeated crash sessions and can provide them, along with the exact Windows Event Viewer crash data, if that would help narrow this down. Happy to test a debug build or provide any additional diagnostic info needed.

My Windows machine kept sabotaging your uploader, so linked to my G-drive, if that will work?? If not i'll move to a different machine.

Thanks for for your part in all things good..    excited to get this working once the crash is sorted out.

---

                                                                                                                                              Michael

[Bruce Waddington]

I don't think the problem is with PHD2.  I just tested this on my Windows laptop using the OmniSimulator camera and its associated dynamic (COM) ASCOM driver.  It loops exposure with no problems.  One thing you need to be clear on is that 2.6.14 PHD2 is still a 32-bit app so it can't support guide cameras with sensors that exceed the memory limits of a 32-bit environment.  In order for us to do anything with this, you will need to give us a reproducible test-case using the same ASCOM OmniSimulator environment I used.

And obviously, if you do produce such a test case, you also need to upload the guide and debug logs to our server.  

Regards,

Bruce