This project has moved. For the latest updates, please go here.


Windows 2008 R2 Server - unhandled exception


TaskEditDialog ted = new TaskEditDialog(dct, true, true);
On Windows 2008 R2 Server, logged in as an Administrator, when the ShowDialog() call exits (but before it hits the next line of my code) I am seeing an Unhandled Exception.

On my Windows 10 dev machine it is absolutely fine, on other platforms it also seems fine. It is the specific circumstances that seems to be causing the problem.

Any advice most welcomed. If I can provide more/better diagnostic information I'd be very happy to.

file attachments

Closed Mar 7 at 2:52 PM by dahall


dahall wrote Nov 17, 2016 at 4:52 AM

It definitely has to do with the settings of the TaskDefinition you are passing in. On the Windows 10 system, please capture and send me the XML for the task. I can then unravel it on my test systems to find the bug.

wrote Nov 29, 2016 at 9:24 AM

DonAtVega wrote Nov 29, 2016 at 9:24 AM

HI. Sorry for the delay. Here's the XML of the Task that causes an unhandled exception. This is from a Windows 10 machine. The fault has only been reproduced on WIndows Server 2008 R2. It's fine on other platforms that we've tested.

DonAtVega wrote Nov 29, 2016 at 9:32 AM

Here's the task creation code.

        public static Microsoft.Win32.TaskScheduler.Task CreateDataCommunicatorTask()
            TaskService tsmgr = new TaskService();

            Microsoft.Win32.TaskScheduler.Task dct = tsmgr.GetTask(strings.DataCommunicator2Task);

            if (dct == null)
                string strThisProgram = Assembly.GetEntryAssembly().CodeBase.ToString();
                strThisProgram = strThisProgram.Replace(@"file:///", @"");
                strThisProgram = strThisProgram.Replace('/', '\\');

                TaskDefinition td = tsmgr.NewTask();

                td.RegistrationInfo.Description = strings.ExecuteTheDataCommunicator;

                TimeTrigger tg = new TimeTrigger(DateTime.Now.AddHours(2));
                tg.Repetition.Interval = TimeSpan.FromMinutes(5);


                    tsmgr.RootFolder.RegisterTaskDefinition(strings.DataCommunicator2Task, td);
                    dct = tsmgr.GetTask(strings.DataCommunicator2Task);
                    dct = null;


            return dct;

dahall wrote Jan 31 at 12:50 AM

I finally figured out the problem. It has to do with the UserId tag under the Principal tag. WS2008 doesn't recognize the SID and reports back an empty string for the user name. My code didn't handle the empty string condition and caused an exception. I have fixed the code in 2.5.22, due shortly. In the mean time, if you remove the UserId tag, it should fix your problem as that will default to the current user.

DonAtVega wrote Jan 31 at 7:19 AM

Can't thank you enough. I'll look forward to the release...


wrote Feb 5 at 7:44 PM

DonAtVega wrote Feb 6 at 10:26 AM

I have recompiled my app with the new library, 2.5.22. I'm afraid I get the same error, crashing out just after the dialog closes but before the next line of my code.

dahall wrote Feb 6 at 10:27 AM

Fixed in 2.5.22

** Closed by dahall 05/02/2017 12:44

wrote Feb 6 at 10:27 AM

dahall wrote Feb 6 at 6:09 PM

Well, darn! What settings are you putting on the TaskEditDialog? I'll create the task using the XML and then run those settings and do my test again.

dahall wrote Feb 6 at 6:11 PM

If there are no other settings that those you set with the constructor, please let me know. Also, will you confirm that the user is pressing OK to exit the dialog or does this also happen with Cancel?

wrote Feb 6 at 6:16 PM

dahall wrote Feb 6 at 6:41 PM

Sorry, one more thing. Since you are not using my precompiled assemblies, which version of .NET are you compiling against? I have tested my builds of 2.5.22 for both 2.0, 3.5 and 4.0 in Windows Server 2008 R2 and am able to read in the XML file you provided and display the edit dialog and save changes without error.

wrote Feb 7 at 9:03 AM

DonAtVega wrote Feb 7 at 9:03 AM

Hi David. Thanks so much for your efforts! Much appreciated.

I am using VS2012 to compile a C# project against the .NET 4.5.2 Framework. I added Task Scheduler to the project using NUGET - which makes it effortless! I could upgrade the project to VS2015 and 4.6 and give that a go... I am not compiling Task Scheduler, I have just added the necessary assembly references, using statements etc.

I have attached a code snippet showing how I am launching the TaskEditDialog. A previous attachment has the Task Creation code. I'll comment out the OS check and test pressing Cancel this afternoon.

Thanks for any pointers you can give me.

DonAtVega wrote Feb 7 at 10:34 AM

I have just tested again on Windows Server 2008 R2. Once the dialog has displayed I can press either OK or Cancel and get the same crash. I'm going to upgrade the project to VS2015 and see if that makes a difference. If it remains unreproducible I'll put the project/compiler on the server and try to use the debugger to step to the point of failure.

Thanks for your help.

DonAtVega wrote Feb 7 at 1:17 PM

I upgraded the project to VS2015 and .NET to 4.6.
Exactly the same problem.

I'm going to put VS2015 on the server I can reproduce the problem on and step the code. I'll let you know what I find...

dahall wrote Feb 7 at 11:11 PM

Two questions:
  1. Have you tried creating a very simple task with something like TaskService.Instance.AddTask("Test", QuickTriggerType.Daily, "myprogram.exe") to see if the dialog fails still?
  2. Will you send me the code behind util.CreateDataCommunicatorTask()?

wrote Feb 8 at 1:19 PM

DonAtVega wrote Feb 8 at 1:19 PM

I've attached the util.CreateDataCommunicatorTask function.
This afternoon I hope to compile and step my project on the W2008R2 server that I have reproduced the issue on. Thanks as always.

wrote Feb 8 at 2:36 PM

DonAtVega wrote Feb 8 at 2:36 PM

Got this from the debugger:

System.AccessViolationException was unhandled
Message=Attempted to read or write protected memory. This is often an indication that other memory is corrupt.
   at System.Windows.Forms.UnsafeNativeMethods.CallWindowProc(IntPtr wndProc, IntPtr hWnd, Int32 msg, IntPtr wParam, IntPtr lParam)
   at System.Windows.Forms.NativeWindow.DefWndProc(Message& m)
   at System.Windows.Forms.Control.WndProc(Message& m)
   at System.Windows.Forms.ComboBox.WndProc(Message& m)
   at System.Windows.Forms.DisabledItemComboBox.WndProc(Message& m)
   at System.Windows.Forms.NativeWindow.DebuggableCallback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam)
   at System.Windows.Forms.UnsafeNativeMethods.SendMessage(HandleRef hWnd, Int32 msg, Int32 wParam, Int32 lParam)
   at System.Windows.Forms.ComboBox.get_SelectedIndex()
   at System.Windows.Forms.ComboBox.OnHandleDestroyed(EventArgs e)
   at System.Windows.Forms.Control.WmDestroy(Message& m)
   at System.Windows.Forms.Control.WndProc(Message& m)
   at System.Windows.Forms.ComboBox.WndProc(Message& m)
   at System.Windows.Forms.DisabledItemComboBox.WndProc(Message& m)
   at System.Windows.Forms.NativeWindow.DebuggableCallback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam)

Some kind of memory leak?

DonAtVega wrote Feb 8 at 2:37 PM

I'll do the very simplest program I can and see if I can reproduce the issue with that, next.

dahall wrote Feb 8 at 4:23 PM

That is a very strange error. From the trace, it appears that on close, the combo box at the bottom of the form that selects compatibility is having an internal message pump problem. The handler is the native .NET combo box. I'll check my code on how I'm handling close events on the subclass I created. I created a very simple 4.5.2 app with the 2.5.22 NuGet packages and don't see the same failure.

DonAtVega wrote Feb 9 at 7:24 AM

Back in the day when I was a C Win16/Win32 programmer you'd get odd crashes due to message pump issues. You'd solve them (mostly) by having the code send a message to itself to carry on... In VB the equivalent was DoEvents. I've never needed the C# equivalent - yet. It's an odd one.

It works fine on every other platform I have tried so please don't expend too much in the way of valuable effort on this.

DonAtVega wrote Feb 9 at 10:51 AM

Hi David,

I have built the smallest simplest possible program to test this issue and, as you might guess, the problem does not reproduce at all. The name of the task is different but everything else is the same. So although the code is breaking inside the TaskEditor dialog the problem must be external to it.

The application the library is embedded in is highly complex with SQL CE, multi-threading background tasks and other things going on. Take all that away and the problem is disappears.

So this is my problem. Please don't waste any more of your valuable time on this. Thank you for your time and assistance, it is much appreciated.

dahall wrote Feb 9 at 2:38 PM

Thank you for your work to isolate the problem and for calling off my hunt. Best of luck in finding the problem. I had a thought, try setting the parameters on the constructor to (task, true, false) which will not re-register the task on exit. If the ShowDialog method returns DialogResult.OK, then register the task yourself. It is a long shot, but definitely simplifies the code run inside my library.

wrote Mar 7 at 2:52 PM