Application freeze
-
Hi there, I've got a real annoying issue with an extremely simple .net application (C#, .net3.5). What I have is a simple program (comparable to Hello World) which launches a thread to periodically read an xml file and stores some values into memory which are used by the main app thread. The main application thread just looks for mouse events on a traybar-icon which open a webbrowser with a specific url. That's it. What the problem is, is that on my dev-machines and home computers the app runs nicely for hours/days straight. On my work-pc, the application seems to enter in a blocked state on the main execution thread or it enters a deadlock/filelock or something after a few minutes and stops responding and the process has to be killed via the taskmanager. This only happens on my work-machine which is Windows XP with .net4.0 installed. All other machines are also windows XP (any flavor) with .net3.5 installed. No error windows or logging present. I'm at a total loss here. I ran through the code numerous times and checked all IO/Threading routines, but no loose ends found. Any ideas what it might be? Could it be the 4.0 runtime? (which I seriously doubt)
A good programmer is someone who always looks both ways before crossing a one-way street. (Doug Linder)
-
Hi there, I've got a real annoying issue with an extremely simple .net application (C#, .net3.5). What I have is a simple program (comparable to Hello World) which launches a thread to periodically read an xml file and stores some values into memory which are used by the main app thread. The main application thread just looks for mouse events on a traybar-icon which open a webbrowser with a specific url. That's it. What the problem is, is that on my dev-machines and home computers the app runs nicely for hours/days straight. On my work-pc, the application seems to enter in a blocked state on the main execution thread or it enters a deadlock/filelock or something after a few minutes and stops responding and the process has to be killed via the taskmanager. This only happens on my work-machine which is Windows XP with .net4.0 installed. All other machines are also windows XP (any flavor) with .net3.5 installed. No error windows or logging present. I'm at a total loss here. I ran through the code numerous times and checked all IO/Threading routines, but no loose ends found. Any ideas what it might be? Could it be the 4.0 runtime? (which I seriously doubt)
A good programmer is someone who always looks both ways before crossing a one-way street. (Doug Linder)
there is insufficient information. is it a WinForm app? if so, is another thread trying to access some of the Controls? do you have proper exception handling? are all exceptions caught and logged? are you swallowing some? when it blocks, is the CPU load near zero? or rather near one fully occupied core?
Helfdane wrote:
an extremely simple .net application
so why not show all relevant code? :)
Luc Pattyn [Forum Guidelines] [My Articles] Nil Volentibus Arduum
Please use <PRE> tags for code snippets, they preserve indentation, improve readability, and make me actually look at the code.
-
there is insufficient information. is it a WinForm app? if so, is another thread trying to access some of the Controls? do you have proper exception handling? are all exceptions caught and logged? are you swallowing some? when it blocks, is the CPU load near zero? or rather near one fully occupied core?
Helfdane wrote:
an extremely simple .net application
so why not show all relevant code? :)
Luc Pattyn [Forum Guidelines] [My Articles] Nil Volentibus Arduum
Please use <PRE> tags for code snippets, they preserve indentation, improve readability, and make me actually look at the code.
Fair questions, my bad for the insufficient info. I can't access the sources from this machine and I'm not going to type it over ;) It's a windows application. The values read from the xml are used to populate a context menu on a traybar icon. So, there is the main app-thread which reads values from a class (GetValues()) and uses those values to build a contextmenustrip. There is one thread which reads an xml-file and stores the values into memory (properties of the value-class). (polls an xml file for updates) Cpu load is 0% at all times, the application is too small to notice it on a dualcore. Memory usage is 21kb. But if this was a logic-issue, I should have problems on all machines, not just one of the 5. The only thing different between those machines is that the one machine which hangs the app has .net4.0 runtime installed, the others are still on 3.5. So, hence my question ;)
A good programmer is someone who always looks both ways before crossing a one-way street. (Doug Linder)
-
Fair questions, my bad for the insufficient info. I can't access the sources from this machine and I'm not going to type it over ;) It's a windows application. The values read from the xml are used to populate a context menu on a traybar icon. So, there is the main app-thread which reads values from a class (GetValues()) and uses those values to build a contextmenustrip. There is one thread which reads an xml-file and stores the values into memory (properties of the value-class). (polls an xml file for updates) Cpu load is 0% at all times, the application is too small to notice it on a dualcore. Memory usage is 21kb. But if this was a logic-issue, I should have problems on all machines, not just one of the 5. The only thing different between those machines is that the one machine which hangs the app has .net4.0 runtime installed, the others are still on 3.5. So, hence my question ;)
A good programmer is someone who always looks both ways before crossing a one-way street. (Doug Linder)
As you are not touching any GUI parts from a thread other than the main thread, it sounds like a deadlock; you seem to have a producer-consumer relation between two threads, possibly there is insufficient synchronization. Maybe you are sharing several data items, and a thread switch occurs when the shared data is in an inconsistent state. Maybe you allowed for a compiler optimization that isn't correct (e.g. lacking a
volatilekeyword). OTOH there have been some synchronization changes in .NET 4.0, IIRC they had to adapt a few things to cope with some potential deadlock the way things used to be handled internally. There also is a new "cancellation model". I don't have a reference, and I never saw an actual victim of the old ways. This[^] is something a quick Google brought up, not sure it is related though. I would consider it more likely the problem is in your code itself. It working properly all the time on some machines, and quite some time on the one, does not prove a thing. Bugs don't have to show themselves all the time, that would be too easy... :)Luc Pattyn [Forum Guidelines] [My Articles] Nil Volentibus Arduum
Please use <PRE> tags for code snippets, they preserve indentation, improve readability, and make me actually look at the code.
-
Fair questions, my bad for the insufficient info. I can't access the sources from this machine and I'm not going to type it over ;) It's a windows application. The values read from the xml are used to populate a context menu on a traybar icon. So, there is the main app-thread which reads values from a class (GetValues()) and uses those values to build a contextmenustrip. There is one thread which reads an xml-file and stores the values into memory (properties of the value-class). (polls an xml file for updates) Cpu load is 0% at all times, the application is too small to notice it on a dualcore. Memory usage is 21kb. But if this was a logic-issue, I should have problems on all machines, not just one of the 5. The only thing different between those machines is that the one machine which hangs the app has .net4.0 runtime installed, the others are still on 3.5. So, hence my question ;)
A good programmer is someone who always looks both ways before crossing a one-way street. (Doug Linder)
Helfdane wrote:
I can't access the sources from this machine and I'm not going to type it over
Post a relevant snippet demonstrating the problem when you do have access. I'm not going to hunt for something without a map.
Helfdane wrote:
But if this was a logic-issue, I should have problems on all machines
Why? Some logical errors only become visible under specific circumstances.
Helfdane wrote:
The only thing different between those machines is that the one machine which hangs the app has .net4.0 runtime installed, the others are still on 3.5.
Is the app also compiled against 4.0, or is it running on the 3.5 framework? Are you by any chance using WM_NCHITTEST on the trayicon?
I are Troll :suss:
-
As you are not touching any GUI parts from a thread other than the main thread, it sounds like a deadlock; you seem to have a producer-consumer relation between two threads, possibly there is insufficient synchronization. Maybe you are sharing several data items, and a thread switch occurs when the shared data is in an inconsistent state. Maybe you allowed for a compiler optimization that isn't correct (e.g. lacking a
volatilekeyword). OTOH there have been some synchronization changes in .NET 4.0, IIRC they had to adapt a few things to cope with some potential deadlock the way things used to be handled internally. There also is a new "cancellation model". I don't have a reference, and I never saw an actual victim of the old ways. This[^] is something a quick Google brought up, not sure it is related though. I would consider it more likely the problem is in your code itself. It working properly all the time on some machines, and quite some time on the one, does not prove a thing. Bugs don't have to show themselves all the time, that would be too easy... :)Luc Pattyn [Forum Guidelines] [My Articles] Nil Volentibus Arduum
Please use <PRE> tags for code snippets, they preserve indentation, improve readability, and make me actually look at the code.