Fixed occasional application crashes when run under a Terminal Services session.

[ribbons]

Original report from Martin Lancaster at 14:49:39 on 2010-11-01

With application running in the systray, there is no instance of this bug.

However, with the interface open, and at random times, the search dialogue will be shown with a red border and a red cross on that border. At that time the crash reporter is hidden behind the interface window. (Reports have been previously sent via the crash reporter mechanism). Note that the crash only occurs when the interface is open.

Once a crash report is sent, the application closes.

Restarting the application and the application runs again.

I have attempted to force a crash by doing various operations with the interface, but without success.

---

Imported from Bug 334 in the NerdoftheHerd.com Bugzilla.

[ribbons]

Original comment from Matt Robinson at 07:25:04 on 2010-11-02

Many thanks for your bug report. Could you attach a screenshot of the application it is displaying the red square with a cross in it?

Also:

• How long (roughly) would you say the application will generally have been running before it crashes like this.
• How often does this occur for you?
• How many programmes are you subscribed to & approximately how many episodes do you download a week?

[ribbons]

Original comment from Martin Lancaster at 08:06:40 on 2010-11-02

Many thanks for your bug report. Could you attach a screenshot of the application it is displaying the red square with a cross in it?

Also:

• How long (roughly) would you say the application will generally have been running before it crashes like this.
• How often does this occur for you?
• How many programmes are you subscribed to & approximately how many episodes do you download a week?
  1. Next time it crashes, I'll grab a screenshot and update this report
  2. Running time varies. If application is left to run in the systray, it does not crash. If the interface is open it will, more than likely, crash at some point. Fastest has been within a couple of minutes of opening the interface. Slowest has been in excess of 72 hours.
  3. If the interface is open, then once or twice a week.
  4. Current subscription count is 21. Majority are weekly downloads, but there are a number that are daily.

Be aware that this is issue has only started since upgrading to version 18 of the application, and seems to be related to the new Search dialogue on the downloads page.

You should have received a number of automated crash reports from me about this?

FYI, running on W2k3 server R2 Enterprise SP2. 2 x AMD Opteron 250 with 1GB Ram. Machine is being used as a file server and email server (hMailServer). Some development websites installed (using Apache), and machine has a DynDNS address.

Will update with the screenshot when it happens again.

[ribbons]

Original comment from Martin Lancaster at 09:20:30 on 2010-11-02

[ribbons]

Original comment from Martin Lancaster at 09:21:08 on 2010-11-02

[ribbons]

Original comment from Martin Lancaster at 09:31:45 on 2010-11-02

It has just crashed!

Two images uploaded:

1. Image showing error report and redrawn Search dialogue - This one shows the search dialogue with a red border and the red cross, with the text "Search Downloads" drawn on top of the cross.
2. Image of error report contents - this shows the information displayed when "What data does this error report contain?" is clicked on the "Please tell NerdoftheHerd.com about this problems" screen.

Immediately prior to the crash I had done:

1. On another machine which has a mapped drive in Explorer to the machine running RDL, I renamed one of the files ("Charles Chilton - Journey into space......") to "Episode 11.mp3"
2. I then moved the renamed file to another folder.
3. Noticed that Radio Downloader had crashed.

After getting the images for this update, I then clicked "Send Error Report", which was sent and then the application closed. Restarted the application, opened the interface and then opened the Downloads tab.

Tried to replicate the crash by renaming and moving two more files, but application did not crash. After uploading the two images and then typing this (so about 10 minutes) checked Radio Downloader interface and it had again crashed. Did not send error report. Rrestarted Radio Downloader, and did same rename and move as before. Application did not immediately crash, but then, about 5 minutes later it did - is there a timer running here??

Note: On restarting the application the Downloads page continues to show the episodes that have been renamed and moved. (Not sure if that helps, but worth pointing out!)

Regards,

Martin

[ribbons]

Original comment from Matt Robinson at 13:40:19 on 2010-11-06

Thanks for all of the information. I've checked in my error reporting system, and there have only been 9 reports of this particular crash, which leads me to suspect that this may well be a Server 2003 specific issue.

I've had a look at the code for the search box, and there isn't anything that would obviously be causing this issue (and the error message isn't exactly helpful...). However, I can see one section of code that is running on XP and Server 2003 which is only needed on Vista and later and may be causing the issue. I will try changing the logic so it doesn't run on Server 2003 and then ask you to try it so we can see if that resolves the issue.

[ribbons]

Original comment from Martin Lancaster at 12:43:06 on 2010-11-08

Thanks for all of the information. I've checked in my error reporting system, and there have only been 9 reports of this particular crash, which leads me to suspect that this may well be a Server 2003 specific issue.

I've had a look at the code for the search box, and there isn't anything that would obviously be causing this issue (and the error message isn't exactly helpful...). However, I can see one section of code that is running on XP and Server 2003 which is only needed on Vista and later and may be causing the issue. I will try changing the logic so it doesn't run on Server 2003 and then ask you to try it so we can see if that resolves the issue.

Hi Matt,

Many thanks for the update. If you want to send me either an exe, msi or url link to the fixed version before general release, then no problem. For your information, my full time employment is as a Software Tester for a software house in Yeovil, and I therefore have access to test tools such as AQ's Test Complete and Seapine's QAW. Equally, if you want me to run some development code to try and tie down this bug, then would be happy to so do.

I have access to XP, Vista and Win7 along with Win 2000 and Win 2003, so it can be run in a number of different environments here. Please note that Vista, Win 7 and Win 2000 are run as virtual machines within VMWare.

Look forward to hearing from you.

Martin

[ribbons]

Original comment from Matt Robinson at 20:30:05 on 2010-11-10

... If you want to send me either an exe, msi or url link to the fixed version before general release...

Will do - am just in the middle of wrestling with cleaning up the codebase after converting it to c#, so there will be a slight delay, but I should hopefully finish the cleanup this weekend time permitting, and can make some tweaks and send you a build after that.

... For your information, my full time employment is as a Software Tester for a software house in Yeovil...

Ah, lovely, that would explain the detailed information and repro steps :)

[ribbons]

Original comment from Martin Lancaster at 10:26:14 on 2010-11-15

Just to let you know that the beta is now installed.

I've tried moving a couple of downloads so that they are no longer in the download folder, and it has not thrown the error. RDL is now open on the desktop of the server (which appears to be the catalyst that has caused the fatality in the previous version), and will monitor over the next 48 hours.

Regards,

Martin

[ribbons]

Original comment from Martin Lancaster at 08:51:26 on 2010-11-15

I adjusted the SearchBox class so that it doesn't call SetWindowTheme on XP and Server 2003 (as the call is only required on Vista and later) in c83edf7.

I've made a quick build of the current trunk, including this change at http://www.nerdoftheherd.com/tools/radiodld/downloads/beta/Radio%20Downloader.msi which I'd appreciate if you would be able to test on Server 2003.

You'll need to uninstall your current version first, as the build still has the same version number as the currently released version.

Hi Matt,

OK, I'll do as you have asked and let you know the result.

Regards,

Martin

[ribbons]

Original comment from Matt Robinson at 07:29:47 on 2010-11-15

I adjusted the SearchBox class so that it doesn't call SetWindowTheme on XP and Server 2003 (as the call is only required on Vista and later) in c83edf7.

I've made a quick build of the current trunk, including this change at http://www.nerdoftheherd.com/tools/radiodld/downloads/beta/Radio%20Downloader.msi which I'd appreciate if you would be able to test on Server 2003.

You'll need to uninstall your current version first, as the build still has the same version number as the currently released version.

[ribbons]

Original comment from Martin Lancaster at 14:41:40 on 2010-11-15

[ribbons]

Original comment from Martin Lancaster at 14:42:11 on 2010-11-15

[ribbons]

Original comment from Martin Lancaster at 14:42:44 on 2010-11-15

[ribbons]

Original comment from Martin Lancaster at 14:49:40 on 2010-11-15

Hi Matt,

Sorry, but the beta you asked me to load has crashed in similar fashion to the original bug report. Three new images added to this bug report for your inspection.

To replicate:

I removed the original RDL, and installed the new beta version that you directed me to. Ran the application, and left it with the GUI open on the Downloads page.

Checked the server about 3 hours later, and discovered this crash.

New images created, crash report sent via the crash dialogue, and updated this report

Restarted RDL, without problems, and "minimised" it to the ssytray using the top right red "close application" button.

Will update if it crashes now that it is minimised to systray, although I doubt that it will (as the original bug was only seen when the GUI was active).

Do you want to let me have a build with logging information being created to try and narrow this one down? Could it be a Framework issue? I have the following frameworks showing in C:\windows\Microsoft.NET\Framework v1.0.3705 v1.1.4322 v2.0.50727 v3.0 v3.5

Regards

Martin

[ribbons]

Original comment from Martin Lancaster at 20:37:11 on 2010-11-15

Hi Matt,

1. Yes, all operations that are completed on the server are done using Remote Desktop. Apart from when I first built the software on the server, it does not have vdu, nor keyboard, nor mouse connected to it.
2. Yes, Framework 3.5 SP 1 is installed
3. Cannot see anything in Event Viewer relating to RDL, other than the uninstall of the application and the reinstall of the beta version.

Be aware that when I left the GUI open and running there were no remote desktop sessions. Effectively, then, it crashed whilst the server was "running blind".

Await hearing!

Regards,

Martin

[ribbons]

Original comment from Matt Robinson at 18:26:10 on 2010-11-15

Never mind, it was just a shot in the dark really. Few more thoughts:

• Are you connecting via remote desktop to the Server 2003 machine?
• Have you got Service Pack 1 for .NET 3.5 installed? (You can check the installed version under Add / Remove programs in the control panel)
• Is there anything useful in the Windows event log at the times when Radio Downloader crashes?

[ribbons]

Original comment from Matt Robinson at 07:24:12 on 2010-11-16

Aha, in that case - I believe the fact that you are running the application under a terminal services session may be the key piece of information.

On the MSDN page for Graphics.Clear (which is the command that had been crashing with the non-specific error message), it says:

"The Clear method clears the state of the graphics object and should not be called when the graphics object cannot be updated. For example, if the Clear method is called on a secure desktop in a terminal server session, an ExternalException may occur, leaving the Graphics object in an inconsistent state."

From the other searches that I did around this issue the above behaviour appears to be due to an underlying bug in GDI+.

I've replaced Clear with a call to FillRectangle which should achieve the same result visually, and updated the build - could you try downloading it again (same link as before) and see if this makes a difference? Make sure that your browser hasn't cached the previous download, the new one should be 4,924,928 bytes in size.

[ribbons]

Original comment from Martin Lancaster at 09:18:04 on 2010-11-16

Hi Matt,

Have now removed yesterdays installation, and downloaded and installed the second msi.

It is running now, with the GUI open on the server desktop.

Will update you when / if it crashes.

Regards,

Martin

[ribbons]

Original comment from Martin Lancaster at 09:33:58 on 2010-11-16

Hi Matt,

The seconds MSI has crashed.

1. Remove (via Add/Remove Programs in Control Panel) RDL.
2. Install latest MSI.
3. Application starts with "Find Programme" tab selected
4. Select "Subscription" tab
5. Select any subscription now visible.
6. Select "Current Episode" button
7. Application crashes.
8. On crash dialogue, select "What does this error report contain?"
9. New window - "UE has occurred..... Object reference not set to an instance of an object"
10. Click "Details": \ Exception Text ** System.NullReferenceException: Object reference not set to an instance of an object. at RadioDld.ReportError.LinkWhatData_LinkClicked(Object sender, LinkLabelLinkClickedEventArgs e) in e:\Visual Studio\Radio Downloader\Forms\ReportError.cs:line 75 at System.Windows.Forms.LinkLabel.OnLinkClicked(LinkLabelLinkClickedEventArgs e) at System.Windows.Forms.LinkLabel.OnMouseUp(MouseEventArgs e) at System.Windows.Forms.Control.WmMouseUp(Message& m, MouseButtons button, Int32 clicks) at System.Windows.Forms.Control.WndProc(Message& m) at System.Windows.Forms.Label.WndProc(Message& m) at System.Windows.Forms.LinkLabel.WndProc(Message& msg) at System.Windows.Forms.Control.ControlNativeWindow.OnMessage(Message& m) at System.Windows.Forms.Control.ControlNativeWindow.WndProc(Message& m) at System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam)

(Note RDL is installed on C:\Program Files\Radio Downloader - E:drive is my backup drive on the server)

Option to send Error Report was clicked.

1. As an aside, please note that the first beta msi you gave me which was running yesterday, did not download any radio programmes - it should have brought down at least 3 episodes of different subscriptions.

Let me know what you want me to do!

Regards,

Martin

[ribbons]

Original comment from Martin Lancaster at 09:44:59 on 2010-11-16

Matt,

I've also installed the second MSI onto a live (ie not a Virtual) XP box (which has a monitor and keyboard and a mouse connected!!), and the application is throwing a UE there as well, I'm afraid.

It is the same UE as the one reported in Comment 20 (ie making reference to the E: drive), which on the XP box, does not exist.

Martin

[ribbons]

Original comment from Martin Lancaster at 18:44:50 on 2010-11-16

Hi Matt,

It is running at the moment, but... it hasn't downloaded anything. Equally, though, it has not crashed in accord with the original crash report.

FYI, I have changed the installed version on the virtual XP box to the current v18 build (ie the one available from the NOTH website). Although the Virtuals use a different workgroup, they do still connect to the 'net via the same router which is also being used by the Win2k3 server.

On the XP box I have recreated all of the subscriptions that exist on the W2k3 box, hence I can affirm the report above that the W2k3 installation of RDL, although not crashing, is not downloading the episodes of subscriptions that the virtual XP box has captured.

w2k3 is connected to the "KestrelNetwork" workgroup. Virtuals are connected to "Workgroup" workgroup.

I'm letting you know this in case you consider that there is a conflict between the two installs, but I don't think that this should be the case in view of the different workgroup names. However, who knows when Mickyduff is involved?? :-)

I'll monitor for another 48 hours or so, and will update you on Thursday.

Regards

Martin

[ribbons]

Original comment from Matt Robinson at 18:22:18 on 2010-11-16

My guess would be that you are running into a couple of other different issues which have resulted from the conversion of the application to c# - it is a bit on the buggy side at the moment, rather than the original issue. Could you leave the application running for a while without pressing Current Episodes to see what happens?

[ribbons]

Original comment from Martin Lancaster at 07:45:14 on 2010-11-19

Hi Matt,

Sorry for the delay - I was away for the office yesterday :-(

I've removed, via Control Panel, beta 2, and have now installed Beta 3.

1. The error that was produced when clicking Current Episodes on the Subscription tab has not replicated, so that looks like a fix.
2. Application is now running, with the Downloads tab open, and the GUI showing on the desktop (which should cause the app to crash).

I'm away now for the weekend but will RD to the server to check on it's progress and to also ensure that it is downloading new episodes correctly (it should do at least one download on Saturday afternoon and a couple on Sunday).

I'll update this Bug on Monday 22nd Nov with results.

Oh, and I have beta 3 installed on the VM XP box as well now.

Till Monday.

Regards,

Martin

[ribbons]

Original comment from Matt Robinson at 19:36:26 on 2010-11-17

Right, I've updated the test build again - same url as before, 4,925,440 bytes this time

I've fixed the bug which was causing the error reporting code to crash, so if you could install this new build and try 'Current Episodes' again, you should be able to get a screen grab of the stack trace for the real error! If you do manage this, would appreciate it if you could open a fresh bug for that issue, as it isn't related to the initial problem you reported in this bug...

Let me know how the build you have installed (and this new build) fare regarding the search box crashes, as if the problem does appear to now be resolved, I'll commit the fix and close this as resolved.

[ribbons]

Original comment from Martin Lancaster at 13:18:34 on 2010-11-22

Hi Matt,

Good news and bad news.

1. Good news is that RDL beta 3 has been running since Friday (19th November) with the Downloads page showing on both w2k3 and XP VM and has not crashed.

BUT

1. Bad news is that RDL beta 3 has not downloaded anything on either the W2k3 box nor the XP VM box.

On a third machine (runnign XP), I have installed the currently available Public download of RDL, and that has downloaded the 9 epsiodes that the other two machines have missed. To check that beta 3 is not downloading, I have removed that from the XP VM, and reinstalled the Public version. After starting, within 15 minutes that had recognised that 9 epsiodes needed to be downloaded and did so.

Where to now?

Regards

Martin

[ribbons]

Original comment from Matt Robinson at 19:59:25 on 2010-11-23

It is good to hear that the application hasn't crashed, so that sounds like a fix for the issue that this bug is about. I've committed it as 0f71a31, but I'll also backport it to 0.18.2 which should hopefully be released shortly, and won't contain the bugs introduced in the recent conversion and refactoring which you are currently running into.

[ribbons]

Original comment from Martin Lancaster at 20:12:28 on 2010-11-23

Hi Matt,

Many thanks for the update - I'll get 18.02 as soon as you make it available on the Public site.

What do you want me to do about the non downloading of episodes that I noted in beta 3? Raise a new ticket, or wait for a new beta?

Regards

Martin

[ribbons]

Original comment from Matt Robinson at 07:14:51 on 2010-11-26

What do you want me to do about the non downloading of episodes that I noted in beta 3? Raise a new ticket, or wait for a new beta?

I think it is probably fixed in development now, I found a bug that seemed to fit the bill, so best to leave it for the moment.

---

Have backported the fix for this issue to the branch of 0.18 in revision 1083 for inclusion in the 0.18.2 release.