SharpCap Forums

So thats all the pieces of the two logs:

2026-01-22 SharpCap log that failed at 02:47a in three parts, which failed with out of memory error during "Save current live stack (FITSRawStack32Bit)" in the FitsFileWriter

2026-01-25 SharpCap Log that failed at 03:25a in four parts, which failed with out of memory error during "Save current live stack (PNGWithStretch)" while attempting to write a png file

Hi,

thanks for that - it's going to take me a while to work through that lot to try to work out what is going on. Particularly as I did some digging into this last night and found a book-keeping error in the diagnostics of how many memory buffers are currently in use. That leads to the log showing more buffers in use than there really are, meaning that some of the information in the log is unreliable

cheers,

Robin

Memory leaks are such a pain to track down. I commiserate.

One additional clue I had forgotten to mention.

I have been starting sharpcap around 5:30pm to cool down the camera, the. Around 6:20pm I start operations preparing to image (getting CPWI and the mount pointing properly) and then start imaging around 7:00pm. The memory failure occurred at around 3am in both cases. My code detected the problem, safed the camera and mount. I got up between 6am and 8am and handled saving logs and shutting down everything. If the error hadn’t occurred my script would have imaged until dawn at 6am.

In both the cases with the Sharpcap memory failure, CPWI was still running properly and connected to the mount, but with the mount homed and tracking disabled by my sharpcap mount safing script.

The third day or capture (between the failures), seeing was terrible, so I shot targets all night from 7pm to 6am. And my sharpcap script terminated normally at 6a, closed live stacking, homed the scope, safed and closed the camera and all was good. However, when I got up at 8am CPWI had thrown an out of memory error sometime after 6a. It was failing to allocate a bitmap used for plotting its star map display. The out of memory dialog box displayed by CPWI was surprising specific about what had happened.

There seemed to be plenty of memory available, but again, this seems to be some sort of graphic memory resource that sharpcap almost used up and then CPWI finally triggered the failure. I’ll see if I can dig out anything in the CPWI log about its memory failure.

The CPWI has no clear message associated with this crash - there was just an exception has occurred sort of dialog on screen with diagnostics displayted in it as follows in the attachment below. Might just be a red herring, but it could be associated with the SharpCap memory leak issue.

Hi,

So, I think there is some sort of memory leak, but I don't think we will catch it with the current logs because of the book-keeping error in the memory diagnostics and also it seems to be subtle - the process total memory is high, but that is not reflected in the diagnostic values (even allowing for them being out). I will keep digging to see what I can do and find out. I have made a change to the way that the saturation adjustment is applied (this is where the memory failure seems to occur) that reduces the number of copies of the image needed to run the algorithm, so that will help a bit.

I would also suggest a sticking plaster approch for now - tweak your Windows settings and set up a good size page file (16Gb?) - put the settings into manual mode rather than system managed. That might keep things running all night. Usually using a page file would lead to performance issues, but if we are just dealing with memory being allocated, leaked and never used, the system will gradually page out the leaked memory to the page file, hopefully leaving more real memory to continue running. Another sticking plater approach might be to restart SharpCap at one or two points during the session.

cheers,

Robin