Program exceptions on W10 system with long uptime

General Help
1

I have a user of one of my applications that is getting exceptions when his W10 PC has been running for a couple of weeks or more. The exceptions are only in my application and often occur when he hovers over the main menu items. Once the issue is seen, he can restart my application and reproduce it over and over. Rebooting the PC however sees everything return to normal.

I always shut my PCs down at the end of the day, so they’re always pretty clean / fresh when I’m trying to track down reports like this. I’ve never been able to reproduce the exceptions he’s seeing.

How common is it for people to leave their PCs on for weeks / months at a time? Does anyone have any ideas on how whatever baggage Windows is collecting over the weeks can cause an issue with my application?

I’ve asked the user to check free memory both up startup and when he’s getting the exceptions. Could it be that RAM is getting fragmented by other applications (he seems to have a lot of Chrome tabs open) and mine is having trouble getting what it needs?

2

Some people just seem to love not turning off their PCs

In Win 10 it often happens without you even being aware of it.

If “Turn on fast startup (recommended)” is checked, your computer never truly shuts down.

I ended up turning that off as after a few months some drivers got quite confused.

3

A number of my applications are designed to be run 24x7 and are not shut down, or the PCs rebooted, as a normal part of the running procedures. My customers have not reported anything like this.

I also tend to leave my PC on overnight and generally only reboot when I need to install an update, or the machine decides I need to install an update. I use Firefox and have lots of tabs open, and find some of the tabs end up grabbing heaps of memory, which does interfere with the smooth running of the machine. Closing Firefox and restarting it generally seems to get things going again, so maybe ask your customer to close Chrome before restarting your application and see if that makes a difference. I don’t think it is Firefox per se, but some of the scripts run on some of the pages. I suspect Facebook is one of the culprits.

I doubt that my customers have a browser running with a lot of tabs, if they even have a browser running.

4

Likewise, my pc stays on 24x7 and I only ever reboot when I really have to - mostly because I have multiple apps running, cmd windows with history etc and it’s annoying to lose that (I do a lot of command line stuff).

I also have a LOT of tabs open in chrome - that does sometimes cause problems… but I can usually just kill that tab.

1 Like
5

Thanks for the replies. I might ask the user if he can close Chrome the next time the issue crops up and see if restarting my application after Chrome is closed solves it.

6

I just re-read his reports and it seems he did try closing Chrome and the email client, but my program still had issues. Only after the reboot did it work correctly again.

Maybe the available RAM during the issue and after reboot will shed some light on it.

7

Get the user to check taskmanager as well. I have had cases where an app fails, looks closed (ie no icon on taskbar) but still has a process running in memory - which prevents a restart of the app or causes issues.

1 Like
8

The exceptions are only in my application and often occur when he hovers over the main menu items

Classic symptom of a memory leak

9

I am (re)building some of the menus at runtime. No memory leaks reported but I may keep an eye on memory used (in task manager) while I force it to rebuild them.

10

Although on second thought, restarting my application doesn’t fix it. Can a memory leak I’m causing in my application be persistent across application starts?

11

More like a handle leak - sadly delphi often doesn’t handle (pardon the pun) issues where handle allocation fails. @David_Duffy you didn’t mention what exception types you are seeing?

This would be the red flag - sounds like perhaps you are not freeing the old menus when rebuilding it - memory managers don’t report handle leaks. I would try something like process explorer - Process Explorer - Sysinternals | Microsoft Learn

SysInternals also has a tool called Handle, that can help show what handles you have open

Not sure if it will show menu handles or not.

12

I don’t have details on the exact exception yet, just that the application “crashes”.

If it were handles, wouldn’t that also be “fixed” by an application close / open cycle?

13

Do you use something like madExcept or EurekaLog? That would help identify where the exception occurs.

Generally, I would say yes - however I have also seen the case where only restarting worked.

BTW, I have also seen weird app crash issues (with other non delphi applications like thunderbird) when a reboot is pending after windows updates.

14

I’m using madExcept.

I just watched the handle count using Task Manager (you can add all sorts of columns in the Details tab) and found they were increasing each time my error checking routine ran. The amount increased by 22 each time.

By stepping through the code I could see that the increase only happened when it checked one particular data object. One of the checks is for file size and I found I was missing a FindClose statement after using FindFirst.

Checking the object list, there were 22 such items. Not all users use all item types and the amount of each can vary greatly. This could explain the varied user experiences. Once fixed, the handle count remains the same (it goes up by one then down by one) when the error check is invoked.

There are still 900 handles used so I might see how that varies with object list size, etc.

15

Nice catch. Also look at GDI objects, I’ve found countless bugs in third party controls (and my own) over the years where handles to things like brushes, pens etc were leaked - W10 is a lot more forgiving about that so it can take longer to be a problem but it still can be if something is repainted often.

16

Leaking handles etc should be cleaned up once the program terminates. This is associated with the OS not the program. The first thing I thought of when reading the original post is GetTickCount - it cycles after 39 days of windows being up

17

Depending on your version of MadExcept you have, the later versions can check for handle (and other) leaks (performance hit included, obviously).

18

I see it has “Report Resource Leaks” as an option so I might turns that on for testing.

19

I have used CLink by Martin Ridgers https://mridgers.github.io/clink/ for persistent command history across sessions in both old cmd and newer Windows Terminal for many years. Never had any problems with it.

20

I still have at least one user that’s getting exceptions in my application when the mouse is hovered over the menus. The crash report shows the system up time as being 10 days and 1 hour. Some stats from the report:

operating system   : Windows 10 x64 build 19043
system language    : English
system up time     : 10 days 1 hour
program up time    : 16 seconds
processors         : 12x Intel(R) Core(TM) i7-9750H CPU @ 2.60GHz
physical memory    : 5010/16111 MB (free/total)
free disk space    : (C:) 358.80 GB
display mode       : 1536x864, 32 bit
process id         : $70b0
allocated memory   : 98.33 MB
largest free block : 1.32 GB
executable         : MultiPlay.exe
exec. date/time    : 2022-03-16 15:26
version            : 3.0.176.0
compiled with      : Delphi XE
madExcept version  : 5.1.2
callstack crc      : $81966802, $c464089e, $5898efb7
exception number   : 1
exception class    : ERangeError
exception message  : Range check error.

thread $a2d0:
00f2e0f5 +065 MultiPlay.exe main       6293   +8 TfmMain.WMMenuSelect
0050f004 +2d4 MultiPlay.exe Controls   7074  +91 TControl.WndProc
005138c8 +568 MultiPlay.exe Controls   9831 +144 TWinControl.WndProc
005a0728 +594 MultiPlay.exe Forms      3961 +191 TCustomForm.WndProc
00512f68 +02c MultiPlay.exe Controls   9552   +3 TWinControl.MainWndProc
004cd224 +014 MultiPlay.exe Classes   13491   +8 StdWndProc
77a04e7b +04b ntdll.dll                          KiUserCallbackDispatcher
77285806 +016 user32.dll                         CallWindowProcW
005139c8 +0d8 MultiPlay.exe Controls   9872  +30 TWinControl.DefaultHandler
005a299e +05a MultiPlay.exe Forms      5228  +11 TCustomForm.DefaultHandler
005155e5 +0a1 MultiPlay.exe Controls  11066  +20 TWinControl.WMSysCommand
005a3a71 +055 MultiPlay.exe Forms      5837  +14 TCustomForm.WMSysCommand
00f2e424 +2e8 MultiPlay.exe main       6364  +59 TfmMain.WMSysCommand
0050f004 +2d4 MultiPlay.exe Controls   7074  +91 TControl.WndProc
005138c8 +568 MultiPlay.exe Controls   9831 +144 TWinControl.WndProc
005a0728 +594 MultiPlay.exe Forms      3961 +191 TCustomForm.WndProc
00512f68 +02c MultiPlay.exe Controls   9552   +3 TWinControl.MainWndProc
004cd224 +014 MultiPlay.exe Classes   13491   +8 StdWndProc