Author Topic: Bug report: automatic screenshotter stops (Read 38,047 times)

kmatzdorf · « **on:** May 01, 2017, 02:09 PM »

Similar to what I reported for the automatic mode in screenshot captor (http://www.donationcoder.com/forum/index.php?topic=43771.0), I see the same behavior with automatic screenshotter. After running for some period of time (for me it was about 30 hours, capturing every 20 seconds), the application will lock up and stop capturing. I have to kill it and restart it. It would not respond to right click menu from the system tray.

Let me know if there are any logs or other troubleshooting I could do to help pinpoint the problem.

Ath · « **Reply #1 on:** May 01, 2017, 06:56 PM »

Stuff to check:
- Antivirus in use? Have you tried disabling AV for the screenshot-folder?
- Number of files? (@mouser: Maybe an automatic directory creator/rotation after ~1000 files or so, or date/hour based, would be useful)
- Specs of the drive the files are stored on? (Does it handle continuous writing for that amount of time and data?)

kmatzdorf · « **Reply #2 on:** May 01, 2017, 08:34 PM »

Thanks for the reply.

It's a windows 10 virtual machine with a single 50GB virtual drive that has plenty of free space. Don't think there should be any issue with continuous writes. Screenshotter already breaks up files into daily directories. Since I have it set to capture every 20 seconds, that means it would end up with at most 4320 files per directory, which isn't that many. Even a FAT32 filesystem can have 64k files in a directory. And with it only writing changes, it's usually only writing about 1000 files per day.

It is running Avast free antivirus. I haven't excluded any directories, but it is usually pretty good about popping up notifications if it takes any action. I could try that, though.

I'll gather some more data on when it occurs and how many files and how much space is being used the next time it stops and will post here.

mouser · « **Reply #3 on:** May 01, 2017, 09:44 PM »

Question:
Are you using filenames (or folders) with dates+times in them, or by chance are you using filenames that are identical other the automatic numbering?

I'll have to set up a test myself to see what might be causing the trouble. One thing that would be useful to know is if the hanging happens after X number of shots (regardless of the speed of capturing), or if it's happening after some amount of time, even if its only capturing once per hour for example.

Another possibility might be that screenshotting is failing when the pc goes to sleep or something... It may be that that is what the problem is -- I should be able to fix it if I can narrow down the proximal cause..

kmatzdorf · « **Reply #4 on:** May 02, 2017, 06:56 PM »

I'm using the default, where screenshotter creates the directory heirarchy by date and has a timestamp on the files. There are no other files in those directories.

It's happened twice so far (since I only started using it a few days ago). The first time it was after 32 hours, and the second time was after 27 hours. I captured a windows dump file when it hung most recently. Not sure if that helps at all, but I can send it, if you want. It's 114 MB, so I can't attach it here.

The most recent time it hung, it had created 1034 files in the first day's directory and then switched to the second day and had created 694 files in there before it stopped. The very last file written out was all black.

There is no screensaver or automatic power settings enabled. When I come back to the console, it is still showing the screen and there are no error messages. screenshotter is still running, but right click on icon does nothing and double click brings up an empty window. It will not close without being killed.

mouser · « **Reply #5 on:** May 02, 2017, 07:00 PM »

And you say the icon is the red color that it normally only briefly turns while capturing?
I think the best way to identify the problem -- if you are willing -- is for me to send you a debug version that will log some messages to a file while it's running and help me see where it gets stuck.

Ath · « **Reply #6 on:** May 02, 2017, 07:16 PM »

These symptoms smell like a resource (file?, gdi handle?) that's not closed while it should be closed. Eventually the process will run out of that resource, and freezes.

kmatzdorf · « **Reply #7 on:** May 02, 2017, 10:30 PM »

Sure, I'd be willing to run a debug version for you. I guess the windows dump file is of no use?

The icon for Screenshot Captor was red when it froze up, but the icon for Automatic Screenshotter doesn't change... it is still blue with a red dot, showing it is active. It is like that all the time.

worstje · « **Reply #8 on:** May 03, 2017, 07:07 AM »

Another thing I would recommend is to open up Process Explorer and check the properties for the process. In particular, the statistics about the handles (on the performance tab) are where I think you might find a problem; if you run out of handles due to a bug not freeing them up after use you can get some really weird behaviour.

My guess is that the app might be leaking a GDI handle each time it screenshots, but that's just a guess.

You don't even need to wait for an error to occur to test this theory; just look at the numbers when you start it up, leave the app running for a few hours, and then check the numbers again. If any handle has grown considerably (don't forget to account for some minor variance), then that is likely to give mouser a hint as to where he's looking for the problem.

mouser · « **Reply #9 on:** May 03, 2017, 08:31 AM »

Yeah that's worth looking at.

Here's the Process Explorer download page: https://technet.microsoft.com/en-us/sysinternals/processexplorer.aspx

What you want to do is double-click on ScreenshotCaptor.exe to bring up the properties dialog and then click the "Performance" tab to give you something like this:
[attach]

wraith808 · « **Reply #10 on:** May 03, 2017, 04:30 PM »

Have you checked the Event Viewer to see if there might be some other information there?

kmatzdorf · « **Reply #11 on:** May 03, 2017, 06:08 PM »

I will download process explorer and take a look at all of these things and report back here. I have not looked at the event viewer, but I will do that, too.

kmatzdorf · « **Reply #12 on:** May 03, 2017, 07:13 PM »

Nice call, @worstje!! GDI handles definitely seems to be the problem. It just hung again, and I ran process explorer and it says GDI Handles = 9,999. I bet the limit is 10,000.

Hope that helps you track down the problem, @mouser! Let me know if any other information would be useful.

mouser · « **Reply #13 on:** May 03, 2017, 07:23 PM »

Ok looks like I have a GDI leak.. let me see if I can track it down..

worstje · « **Reply #14 on:** May 03, 2017, 07:37 PM »

Yeah, I think 10k is the limit in recent versions of Windows per application. Back in the 9x days, I think the limit was 1024 or something, so go figure. Since they are per-session identifiers and very archaic beasts that date back to the Windows 3.1 era, there's only 16 bits (~=65535) of them total for your entire login session. So six programs that all try to max out the GDI handles will without a doubt give you this crazy madness. (Look into the testlimit tool from Sysinternals, it can do exactly this.

)

Honestly, it is already highly extravagant to have 500 GDI handles in a single process imho, because you can (roughly) equate it with using 500 pencils at the same time. To stick with the comparison: it makes sense not to always put the pencil you are using back into the pack because you know you'll need it again in a moment... but in this case, the program keeps taking pencils out of the pack and dropping them on the desk for re-use.. which never happens. And then suddenly, there's more pencils than desk, and no more work can get done... which is why pretty much anything involving traditional graphics tends to die the moment you run out of GDI handles: windows don't get drawn, menus fail to draw properly, random stuff has black or white squares or whatever..

TL;DR: GDI handle excesses are probably my favorite kind of 'traditional' bug because as much of a pain as it can be to find the source of the leakage, the utter chaos is such a nice change of pace.

mouser · « **Reply #15 on:** May 03, 2017, 07:43 PM »

The embarassing truth is that another DC member posted about the probably GDI leak a long time ago and I never got around to investigating it...

At least now I can more easily track it down and solve it. Stay tuned I hope to have a fix up for testing as soon as possible.

mouser · « **Reply #16 on:** May 03, 2017, 08:51 PM »

Please try beta:

kmatzdorf · « **Reply #17 on:** May 04, 2017, 03:55 PM »

beta version is installed and running. GDI handles currently at 198. Will let you know how it goes. Thanks for the quick turnaround on this.

AbteriX · « **Reply #18 on:** May 04, 2017, 07:20 PM »

Now I had no time to visit this forum for some days and so I missed this thread...

But interesting, I had just this days the same issue with MiniCap (based on ScreenshotCaptor).
I have a script to capture every 3 seconds and on mouse click.
Works fine after I read the help how to make individual file names
for about 20 minutes and ~600 files, then I can't let work MiniCap again.
(VirtualPC W7/64, only 2GB RAM)

I wanted to look on GDI issue too, but then there were other things to do.
I switched to Automatic Screenshotter and that works fine with "every 3 sec" rule, but I miss "capture on mouse click".
So it's fine you work on that already

mouser · « **Reply #19 on:** May 04, 2017, 07:35 PM »

Quote

but I miss "capture on mouse click".

I will look into adding this option to Automatic Screenshotter.

mouser · « **Reply #20 on:** May 05, 2017, 01:22 PM »

Anxiously awaiting news that this is a good fix.

kmatzdorf · « **Reply #21 on:** May 05, 2017, 01:53 PM »

Looks like you did it. It's still running, and GDI handles are steady at 199. Thanks much for the quick fix!

mouser · « **Reply #22 on:** May 05, 2017, 02:10 PM »

Awesome!
I'll push out an official update now.