In version 2.2.1 there is a bug that causes WillowTree# to stop responding if it is unable to connect when it tries to check for the current version number on some systems. I believe this was caused by some code in the update check thread that tries to write an event to the Windows event log if it is unable to connect. If a user is unable to write the trace event because of lack of access priviledges or perhaps if the WMI service is disabled it would cause an unhandled exception and I believe that is what was happening.
I have released a hotfix version 2.2.1.101 to hopefully solve this problem, so if you are experiencing this problem please try version 2.2.1.101. Users that have not had this problem do not need to update.
If anyone who previously had the problem could try the new version and tell me if it does solve the problem I'd be grateful. Thank you.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Trace does not notify the event log. All it does (with the default trace listener) is calls OutputDebugString in the Windows API. Many applications use this for developer notifications and the user never even knows it exists (because OutputDebugString doesn't do anything unless a debugger is attached)… the event log is not used at all by these calls.
Also, if you really don't want to handle tracing, simply uncheck TRACE from the project build settings on Release. The methods in Trace are only used when TRACE is defined in the build. If it's not defined, the compiler will ignore all Trace method calls. The Debug methods work exactly the same way (but with the DEBUG definition).
I suspect the issue might be due to another exception not being handled. I only accounted for WebException, but there are obviously other exceptions that must be thrown when WebClient fails.
Also, avoid generic catch statements if at all possible. Serious errors like NullReferenceException can get thrown for good reasons and should be treated like bugs, not ignored. That's the main reason why I use specific exceptions and why Microsoft recommends against catching generic exceptions. Here's a good article about why not to catch Exception (which is the same as a catch without specifying an exception type): http://blogs.msdn.com/b/codeanalysis/archive/2006/06/14/631923.aspx
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I agree that generic catch statements make it both harder to debug software and more likely an error that corrupts your data will be allowed to go undetected, but in the case when you don't know all the possible exceptions that may occur you must either catch all exceptions or allow your program to crash. Since the version number has no effect on the reliability of anything else in the program It is not acceptable for the program to crash no matter what sort of error it runs into while trying to obtain it. A generic catch statement is in order here.
I'm sorry I don't understand the intricacies of event tracing but I will tell you the story of what happened. I received a report from a user that WT# would stall on his laptop that has no internet access. I attempted to make sure that not being able to connect on the version check would not cause WT# to crash. It didn't crash so I told the user that being able to connect for the version check did not matter.
I got another report of the same problem the next day or the day after from another user so I went to look at the code and the only thing I could see in there that could cause the problem is the exception handler. I hypothesized that it is sending events to the Application event log so I went there to look and I found two events corresponding with the time and date where I tested it for the first guy.
It didn't crash on my machine because I'm an administrator so I have write access to everything, but the last user with the problem said he is using Windows Vista in which the normal user account is a limited user with many access restrictions and quite possibly is not allowed to write to the event log because Windows Vista is quite guarded like that and a limited user could probably technically crash or cause it to bog down by writing millions of events to the event log..
The first report of this error did not occur until the code that runs the update check was changed to report these trace events which gives another clue. I believe is a distinct likelyhood that the problem being reported is the result of the same event that I received occuring on these users machines but running into an access problem. You say it doesn't write to the event log, but yet somehow I have these errors in my log of the exact exception that the exception handler was trying to catch which should not have been able to reach my event log because they were handled and replaced with the Trace.Error.:
I tried to play around with the Trace.Error thing in an empty application and you are right that it doesn't seem to send messages to the user log itself, so the problem is not access to the event log, but it may be a problem accessing the trace provider or it may be that the exception handler is making an improper data access (I can't recognize one but that doesn't mean its not there) and is causing an exception itself. The solution to both those problems is the same as the solution I implemented which was is to remove any code that may be causing the problem and see if it goes away. You can't run into a secondary exception in an exception handler that performs no operations so the problem should be solved. I'm not sure what the problem is exactly but I'm pretty sure what I have done is a solution to it.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
In version 2.2.1 there is a bug that causes WillowTree# to stop responding if it is unable to connect when it tries to check for the current version number on some systems. I believe this was caused by some code in the update check thread that tries to write an event to the Windows event log if it is unable to connect. If a user is unable to write the trace event because of lack of access priviledges or perhaps if the WMI service is disabled it would cause an unhandled exception and I believe that is what was happening.
I have released a hotfix version 2.2.1.101 to hopefully solve this problem, so if you are experiencing this problem please try version 2.2.1.101. Users that have not had this problem do not need to update.
If anyone who previously had the problem could try the new version and tell me if it does solve the problem I'd be grateful. Thank you.
Trace does not notify the event log. All it does (with the default trace listener) is calls OutputDebugString in the Windows API. Many applications use this for developer notifications and the user never even knows it exists (because OutputDebugString doesn't do anything unless a debugger is attached)… the event log is not used at all by these calls.
Also, if you really don't want to handle tracing, simply uncheck TRACE from the project build settings on Release. The methods in Trace are only used when TRACE is defined in the build. If it's not defined, the compiler will ignore all Trace method calls. The Debug methods work exactly the same way (but with the DEBUG definition).
I suspect the issue might be due to another exception not being handled. I only accounted for WebException, but there are obviously other exceptions that must be thrown when WebClient fails.
Also, avoid generic catch statements if at all possible. Serious errors like NullReferenceException can get thrown for good reasons and should be treated like bugs, not ignored. That's the main reason why I use specific exceptions and why Microsoft recommends against catching generic exceptions. Here's a good article about why not to catch Exception (which is the same as a catch without specifying an exception type): http://blogs.msdn.com/b/codeanalysis/archive/2006/06/14/631923.aspx
I agree that generic catch statements make it both harder to debug software and more likely an error that corrupts your data will be allowed to go undetected, but in the case when you don't know all the possible exceptions that may occur you must either catch all exceptions or allow your program to crash. Since the version number has no effect on the reliability of anything else in the program It is not acceptable for the program to crash no matter what sort of error it runs into while trying to obtain it. A generic catch statement is in order here.
I'm sorry I don't understand the intricacies of event tracing but I will tell you the story of what happened. I received a report from a user that WT# would stall on his laptop that has no internet access. I attempted to make sure that not being able to connect on the version check would not cause WT# to crash. It didn't crash so I told the user that being able to connect for the version check did not matter.
I got another report of the same problem the next day or the day after from another user so I went to look at the code and the only thing I could see in there that could cause the problem is the exception handler. I hypothesized that it is sending events to the Application event log so I went there to look and I found two events corresponding with the time and date where I tested it for the first guy.
It didn't crash on my machine because I'm an administrator so I have write access to everything, but the last user with the problem said he is using Windows Vista in which the normal user account is a limited user with many access restrictions and quite possibly is not allowed to write to the event log because Windows Vista is quite guarded like that and a limited user could probably technically crash or cause it to bog down by writing millions of events to the event log..
The first report of this error did not occur until the code that runs the update check was changed to report these trace events which gives another clue. I believe is a distinct likelyhood that the problem being reported is the result of the same event that I received occuring on these users machines but running into an access problem. You say it doesn't write to the event log, but yet somehow I have these errors in my log of the exact exception that the exception handler was trying to catch which should not have been able to reach my event log because they were handled and replaced with the Trace.Error.:
Event Type: Error
Event Source: .NET Runtime 2.0 Error Reporting
Event Category: None
Event ID: 5000
Date: 2/24/2011
Time: 6:49:17 PM
User: N/A
Computer: MAIN
Description:
EventType clr20r3, P1 willowtree#.exe, P2 2.2.1.0, P3 4d58fec6, P4 system, P5 2.0.0.0, P6 4ba85929, P7 1fb2, P8 1bd, P9 system.net.webexception, P10 NIL.
For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.
Data:
0000: 63 00 6c 00 72 00 32 00 c.l.r.2.
0008: 30 00 72 00 33 00 2c 00 0.r.3.,.
0010: 20 00 77 00 69 00 6c 00 .w.i.l.
0018: 6c 00 6f 00 77 00 74 00 l.o.w.t.
0020: 72 00 65 00 65 00 23 00 r.e.e.#.
0028: 2e 00 65 00 78 00 65 00 ..e.x.e.
0030: 2c 00 20 00 32 00 2e 00 ,. .2…
0038: 32 00 2e 00 31 00 2e 00 2…1…
0040: 30 00 2c 00 20 00 34 00 0.,. .4.
0048: 64 00 35 00 38 00 66 00 d.5.8.f.
0050: 65 00 63 00 36 00 2c 00 e.c.6.,.
0058: 20 00 73 00 79 00 73 00 .s.y.s.
0060: 74 00 65 00 6d 00 2c 00 t.e.m.,.
0068: 20 00 32 00 2e 00 30 00 .2…0.
0070: 2e 00 30 00 2e 00 30 00 ..0…0.
0078: 2c 00 20 00 34 00 62 00 ,. .4.b.
0080: 61 00 38 00 35 00 39 00 a.8.5.9.
0088: 32 00 39 00 2c 00 20 00 2.9.,. .
0090: 31 00 66 00 62 00 32 00 1.f.b.2.
0098: 2c 00 20 00 31 00 62 00 ,. .1.b.
00a0: 64 00 2c 00 20 00 73 00 d.,. .s.
00a8: 79 00 73 00 74 00 65 00 y.s.t.e.
00b0: 6d 00 2e 00 6e 00 65 00 m…n.e.
00b8: 74 00 2e 00 77 00 65 00 t…w.e.
00c0: 62 00 65 00 78 00 63 00 b.e.x.c.
00c8: 65 00 70 00 74 00 69 00 e.p.t.i.
00d0: 6f 00 6e 00 20 00 4e 00 o.n. .N.
00d8: 49 00 4c 00 0d 00 0a 00 I.L…..
Event Type: Error
Event Source: .NET Runtime 2.0 Error Reporting
Event Category: None
Event ID: 5000
Date: 2/24/2011
Time: 6:49:33 PM
User: N/A
Computer: MAIN
Description:
EventType clr20r3, P1 willowtree#.exe, P2 2.2.1.0, P3 4d58fec6, P4 system, P5 2.0.0.0, P6 4ba85929, P7 1fb2, P8 1bd, P9 system.net.webexception, P10 NIL.
For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.
Data:
0000: 63 00 6c 00 72 00 32 00 c.l.r.2.
0008: 30 00 72 00 33 00 2c 00 0.r.3.,.
0010: 20 00 77 00 69 00 6c 00 .w.i.l.
0018: 6c 00 6f 00 77 00 74 00 l.o.w.t.
0020: 72 00 65 00 65 00 23 00 r.e.e.#.
0028: 2e 00 65 00 78 00 65 00 ..e.x.e.
0030: 2c 00 20 00 32 00 2e 00 ,. .2…
0038: 32 00 2e 00 31 00 2e 00 2…1…
0040: 30 00 2c 00 20 00 34 00 0.,. .4.
0048: 64 00 35 00 38 00 66 00 d.5.8.f.
0050: 65 00 63 00 36 00 2c 00 e.c.6.,.
0058: 20 00 73 00 79 00 73 00 .s.y.s.
0060: 74 00 65 00 6d 00 2c 00 t.e.m.,.
0068: 20 00 32 00 2e 00 30 00 .2…0.
0070: 2e 00 30 00 2e 00 30 00 ..0…0.
0078: 2c 00 20 00 34 00 62 00 ,. .4.b.
0080: 61 00 38 00 35 00 39 00 a.8.5.9.
0088: 32 00 39 00 2c 00 20 00 2.9.,. .
0090: 31 00 66 00 62 00 32 00 1.f.b.2.
0098: 2c 00 20 00 31 00 62 00 ,. .1.b.
00a0: 64 00 2c 00 20 00 73 00 d.,. .s.
00a8: 79 00 73 00 74 00 65 00 y.s.t.e.
00b0: 6d 00 2e 00 6e 00 65 00 m…n.e.
00b8: 74 00 2e 00 77 00 65 00 t…w.e.
00c0: 62 00 65 00 78 00 63 00 b.e.x.c.
00c8: 65 00 70 00 74 00 69 00 e.p.t.i.
00d0: 6f 00 6e 00 20 00 4e 00 o.n. .N.
00d8: 49 00 4c 00 0d 00 0a 00 I.L…..
I tried to play around with the Trace.Error thing in an empty application and you are right that it doesn't seem to send messages to the user log itself, so the problem is not access to the event log, but it may be a problem accessing the trace provider or it may be that the exception handler is making an improper data access (I can't recognize one but that doesn't mean its not there) and is causing an exception itself. The solution to both those problems is the same as the solution I implemented which was is to remove any code that may be causing the problem and see if it goes away. You can't run into a secondary exception in an exception handler that performs no operations so the problem should be solved. I'm not sure what the problem is exactly but I'm pretty sure what I have done is a solution to it.