Hi,
I'm back with the problem of the app crashing. We are currently using PB22 1892, 32bit version.
We are still dealing with random app crashes and there seems to be some connection with GDI objects.
What happens is that if the application crashes due to running out of GDI objects limit, after a new start the application starts crashing earlier, as if there is some allocated memory left somewhere from the previous crash. Restarting the computer will help.
Is there any way to restore the state of the computer without rebooting?
From what I've read, GDI objects belong to a single process, so it's not clear to me how a crashed app can affect a new restarted one.
The tester was able to reproduce it by running the app in multiple instances. The later instances started to crash earlier, they even didn't reach the GDI objects limit.
Any idea what we could do?
Regards,
Tomáš
Manually calling a Garbage collector lead to an even more unexpected behavior of the app. Tested on another occassion.
According to your original post, when multiple instances of the app are opened, the LATER instances abend first. This sure looks like there is but a single source for that GDI counter; meaning I wonder if each instance of the app is seen as a separate instance by Windows.
1. Add the SESSION column to Sysinternals Process Explorer .and look at the values when running one instance. Try to see what action in the app causes the GDI to increase.
2. I also wonder if the app is making multiple connections to the database.
3. Are there web-based activities generated from the app?
I am not sure how Windows handle multiple instances of the same app. I would say they should be independent of each other.
I will try to play a bit with Sysinternals Process Explorer.
One app is making one connection to the DB.
Basically there are no web-based activities during regular work with the app.
Meanwhile our tester found another way to make an app to crash in a different way which also doesn't make sense. I'll have to open a ticket with this issue...