none
The Undo operation encountered a context that is different...

    Question

  • This is not specific enough information for me to know what I did wrong and where. Does anyone have any insight to this? It appears to have something to do with asynchronous socket I/O completion.

    System.Transactions Critical: 0 :
    <TraceRecord xmlns="http://schemas.microsoft.com/2004/10/E2ETraceEvent/TraceRecord" Severity="Critical">
    <TraceIdentifier>http://msdn.microsoft.com/TraceCodes/System/ActivityTracing/2004/07/Reliability/Exception/Unhandled</TraceIdentifier>
    <Description>Unhandled exception</Description>
    <AppDomain>PPSManager.vshost.exe</AppDomain>
    <Exception>
    <ExceptionType>System.InvalidOperationException, mscorlib, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089</ExceptionType>
    <Message>The Undo operation encountered a context that is different from what was applied in the corresponding Set operation. The possible cause is that a context was Set on the thread and not reverted(undone).</Message>
    <StackTrace>   at System.Threading.SynchronizationContextSwitcher.Undo()
       at System.Threading.ExecutionContextSwitcher.Undo()
       at System.Threading.ExecutionContext.runFinallyCode(Object userData, Boolean exceptionThrown)
       at System.Runtime.CompilerServices.RuntimeHelpers.ExecuteBackoutCodeHelper(Object backoutCode, Object userData, Boolean exceptionThrown)
       at System.Runtime.CompilerServices.RuntimeHelpers.ExecuteCodeWithGuaranteedCleanup(TryCode code, CleanupCode backoutCode, Object userData)
       at System.Threading.ExecutionContext.RunInternal(ExecutionContext executionContext, ContextCallback callback, Object state)
       at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state)
       at System.Net.ContextAwareResult.Complete(IntPtr userToken)
       at System.Net.LazyAsyncResult.ProtectedInvokeCallback(Object result, IntPtr userToken)
       at System.Net.Sockets.BaseOverlappedAsyncResult.CompletionPortCallback(UInt32 errorCode, UInt32 numBytes, NativeOverlapped* nativeOverlapped)
       at System.Threading._IOCompletionCallback.PerformIOCompletionCallback(UInt32 errorCode, UInt32 numBytes, NativeOverlapped* pOVERLAP)
    </StackTrace>
    <ExceptionString>System.InvalidOperationException: The Undo operation encountered a context that is different from what was applied in the corresponding Set operation. The possible cause is that a context was Set on the thread and not reverted(undone).
       at System.Threading.SynchronizationContextSwitcher.Undo()
       at System.Threading.ExecutionContextSwitcher.Undo()
       at System.Threading.ExecutionContext.runFinallyCode(Object userData, Boolean exceptionThrown)
       at System.Runtime.CompilerServices.RuntimeHelpers.ExecuteBackoutCodeHelper(Object backoutCode, Object userData, Boolean exceptionThrown)
       at System.Runtime.CompilerServices.RuntimeHelpers.ExecuteCodeWithGuaranteedCleanup(TryCode code, CleanupCode backoutCode, Object userData)
       at System.Threading.ExecutionContext.RunInternal(ExecutionContext executionContext, ContextCallback callback, Object state)
       at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state)
       at System.Net.ContextAwareResult.Complete(IntPtr userToken)
       at System.Net.LazyAsyncResult.ProtectedInvokeCallback(Object result, IntPtr userToken)
       at System.Net.Sockets.BaseOverlappedAsyncResult.CompletionPortCallback(UInt32 errorCode, UInt32 numBytes, NativeOverlapped* nativeOverlapped)
       at System.Threading._IOCompletionCallback.PerformIOCompletionCallback(UInt32 errorCode, UInt32 numBytes, NativeOverlapped* pOVERLAP)
    </ExceptionString>
    </Exception>
    </TraceRecord>

    Monday, December 19, 2005 5:39 PM

Answers

  • I had the same problem in an application which was using the Process class to launch some scripts. I needed one script to complete before running the next etc. In the BETA version of framework V2.0 I found that a check on Process.HasExited (inside a while loop) was not working without following it with a call to Application.Doevents(). i.e. it would always be false and the loop would never exit. I remember having to do this from my old VB6 development days ;-)

    Eliminating the call to Application.Doevents() from my code got rid of the above InvalidOperationException. I also note that my call to Process.HasExited is also working correctly without the DoEvents call.

    Here is the old code;

    Process offProcess = Process.Start(psi);

    while (true)

    {

    //Loop until process has completed

    if (offProcess.HasExited) break;

    Application.DoEvents();

    }

    ...& here is the new code;

    Process offProcess = Process.Start(psi);

    while (true)

    {

    //Loop until process has completed

    if (offProcess.HasExited) break;

    }

    Anyway... I hope this helps.

     

     

    Tuesday, January 10, 2006 5:08 PM

All replies

  • I take it back. Based on my own observations, and the two other such reports I found by Googling, I am convinced this is a socket framework bug. I am also pretty sure it is being caused by a code change between the final beta and the RTM. I just hope someone from MS can respond to this to tell us how to mitigate it. Everyone is being pretty tight lipped about this.
    Tuesday, December 20, 2005 7:58 PM
  • Additional research indicates to me that EXECUTION CONTEXT is cached by the framework when making asynchronous socket calls in order to boost performance. I believe the bug must have something to do with this, and the cache is becoming confused or corrupt. I see the above exception after having made several calls to receive socket data. This is a typical scenario where another asynchronous read is issued in the callback. Again, this all ran fine in framework 1.1.

    Thursday, December 22, 2005 4:07 PM
  • I have had a similar problem when converting a project fro .net framework 1.1 to 2.0.

    Have you found a solution? 

    Friday, December 30, 2005 9:51 AM
  • Yep...

    It appears that is a bug in .NET Framework 2.0 bacause the code runs quite fine in v1.1

    I really don't know what to do... I had tried every trick I know and nothing.

    I'll keep watching this thread to see if someone come up with a soulution.

    I'd like to port all my old codes to v2.0, but sometimes I get stuck in this small things.

    Regards,

    Paulo Silva Jr.

    http://pjondevelopment.50webs.com/

    Saturday, December 31, 2005 2:06 AM
  • Yes, it is definitely something down inside the big black box (i.e. Framework). I did some reorganization, and finally got this to go away. I believe it may have something to do with attempting some kinds of marshalling to the GUI thread sometime after the NEW of a form, and perhaps even after LOAD event, but prior to ACTIVATED event. Since ACTIVIATED is called multiple times I have a form class level member flag that tells me the one-time initialization has been done or not, and if not, deferring various start up activity that COULD result in ansynchronous activity, including sockets, and I/O completion until then. I believe there must be some magic regarding asynchronous socket activity and thread marshalling that is not documented, and we can't see. The redesign seemed to work for me. Please give it a try and report back. It is not looking like we are going to get any help from the people who really know how it works inside. My feeling is that even though it is not documented, there should be some kind of guidance in the documentation that helps steer us away from this.
    Friday, January 06, 2006 4:07 PM
  • I had the same problem in an application which was using the Process class to launch some scripts. I needed one script to complete before running the next etc. In the BETA version of framework V2.0 I found that a check on Process.HasExited (inside a while loop) was not working without following it with a call to Application.Doevents(). i.e. it would always be false and the loop would never exit. I remember having to do this from my old VB6 development days ;-)

    Eliminating the call to Application.Doevents() from my code got rid of the above InvalidOperationException. I also note that my call to Process.HasExited is also working correctly without the DoEvents call.

    Here is the old code;

    Process offProcess = Process.Start(psi);

    while (true)

    {

    //Loop until process has completed

    if (offProcess.HasExited) break;

    Application.DoEvents();

    }

    ...& here is the new code;

    Process offProcess = Process.Start(psi);

    while (true)

    {

    //Loop until process has completed

    if (offProcess.HasExited) break;

    }

    Anyway... I hope this helps.

     

     

    Tuesday, January 10, 2006 5:08 PM
  • I am having the same problem as other's here, I haven't found the solution but my work around involves not opening a window.

    I am performing async socket communication multiple time and when the event is raised informing my client class that the commincations are finished I open a modal form indicating whether or not the operation was successful or not. I get the error when I open the window with ShowDialog but if I comment this out the program finishes without incident.

    I am inclined to believe Lee Gillie in that it must have something to do with the operations performed by the window on or just before display/load. I am going to rasie this issue with Microsoft as I have a support call left to use. If I get anywhere I'll post back here.

    Hopefully this will be sorted soon.

    Friday, January 27, 2006 9:16 AM
  • I don't think so.  My problems with AsyncSockets are happing in an implementation with no UI.  No Form object is ever created.

    I have found that this only heppens when I re-use the same callback delegate.  If I BeginRecieve / BeginSend with a new AsyncCallback(...) each time, it works fine.  I know this is hardly ideal, but... if it works then I don't know that I have much choise.
    Friday, January 27, 2006 2:48 PM
  • Col. Sanders,

    I'm having the same issue. Would you mind expanding on how you're overcoming this problem with a bit of sample code? Thanks.

    Monday, January 30, 2006 6:27 PM
  • Hi all,

    We have encountered this problem as well, in yet another situation. It's a big-time showstopper for us.

    We have one situation where the server needs to interact with the client. It is implemented with a client activated remote object, passed to the server and it talks to it. When the server tries to retrieve a public _field_ it fails with an appdomain exception that we can not swallow.
    I've tried making it a property, to see if it breaks at the getter, but it doesn't: it fails before it.

    Stacktrace:

    1) Exception Information

    *********************************************

    Exception Type: System.InvalidOperationException

    Message: The Undo operation encountered a context that is different from what was applied in the corresponding Set operation. The possible cause is that a context was Set on the thread and not reverted(undone).

    Data: System.Collections.ListDictionaryInternal

    TargetSite: Void Undo()

    HelpLink: NULL

    Source: mscorlib

    StackTrace Information

    *********************************************

    at System.Threading.SynchronizationContextSwitcher.Undo()

    at System.Threading.ExecutionContextSwitcher.Undo()

    at System.Threading.ExecutionContext.runFinallyCode(Object userData, Boolean exceptionThrown)

    at System.Runtime.CompilerServices.RuntimeHelpers.ExecuteBackoutCodeHelper(Object backoutCode, Object userData, Boolean exceptionThrown)

    at System.Runtime.CompilerServices.RuntimeHelpers.ExecuteCodeWithGuaranteedCleanup(TryCode code, CleanupCode backoutCode, Object userData)

    at System.Threading.ExecutionContext.RunInternal(ExecutionContext executionContext, ContextCallback callback, Object state)

    at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state)

    at System.Net.ContextAwareResult.Complete(IntPtr userToken)

    at System.Net.LazyAsyncResult.ProtectedInvokeCallback(Object result, IntPtr userToken)

    at System.Net.Sockets.BaseOverlappedAsyncResult.CompletionPortCallback(UInt32 errorCode, UInt32 numBytes, NativeOverlapped* nativeOverlapped)

    at System.Threading._IOCompletionCallback.PerformIOCompletionCallback(UInt32 errorCode, UInt32 numBytes, NativeOverlapped* pOVERLAP)

     

    Like I said, this is a showstopper for us. So I would be very happy if someone had some more pointers. It looks like the problem is out of my control.

    Regards,

    Ruurd Boeke

    Tuesday, February 07, 2006 2:54 PM
  • Same problem for me.

    I'm doing a porting from 1.1 to 2.0. So I think is definitely a bug in 2.0

    Did someone open a request on this?

    Carlo Folini

    Wednesday, February 08, 2006 1:27 PM
  • We had a similar issue with our web application. In our case, it turned out that we were not always setting the CompletedSynchronously flag correctly within our IHttpAsyncHandler.

    We were able to get a 100% repro scenario with the following two conditions in our web application:

    1. Authorization step in HttpApplication pipeline completes asynchronously with CompletedSynchronously flag = false.
    2. IHttpAsyncHandler completes synchronously with CompletedSynchronously = false.

    The result is that you end up with nested calls to HttpApplication.ResumeSteps when executing Application_EndRequest. After Application_EndRequest completes, the nested call to ResumeSteps sees that the request has completed and cleans up its internal state. This causes the outer call to throw an exception and not restore the SynchronizationContext.

    Before we identified the root cause, we just manually saved and restored the AsyncOperationManager.SynchronizationContext. It doesn't fix the real issue, but it provided a suitable workaround.

    So why does this happen more often in 2.0? Even though we are performing network I/O operations in our IHttpAsyncHandler, many of those operations appear to complete synchronously, so you should always be checking the CompletedSynchronously flag returned in the IAsyncResult in the callback. Something with how the framework manages threads seems to have changed between 1.1 and 2.0 to cause this synchronous I/O completion to happen much more frequently.

    Monday, February 13, 2006 11:59 PM
  • Okay, we have been able to fix our problem.

    What happened was this: we had a clientobject that was being remoted to the server. On the server instructions are given to the client that will create a form to show on the client machine. When the form was closed, the server would continue on with the results. At that moment the exception occurred, (on the client btw).

    What was need to fix this was a simple thread switch on the client before the form was showed on the client. Ofcourse the proxy did not do a threadswitch for us, and returned to the clientobject on a whole different thread then the main ui thread.

    I really hope this helps someone. This was a major showstopper for us!

    Wednesday, February 15, 2006 3:20 PM
  • To Ruurd Boeke:

    Can you post little sample of thread switch?

    Tuesday, February 21, 2006 8:07 AM
  • Here you go:

    private delegate void yourDelegate(string xml);

      public void yourMethod(string xml)
      {
       Form mainForm = yourApplicationState.Get("MainForm") as Form;

       if ( (mainForm != null) && (mainForm.InvokeRequired) )
       {
        mainForm.Invoke(new yourDelegate(yourMethod), new object[] { xml });
       }
       else
       {
           // do your thang.

    }

    }

    Tuesday, February 21, 2006 8:23 AM
  • He means to get back to the GUI thread via form/control calls such as Invoke or BeginInvoke.
    Wednesday, February 22, 2006 8:07 PM
  • Thanks Andrew Stanford -

    Removing application.doevents() fixed this for me as well.

    For what it's worth to whoever is solving this at MSFT:

    My application uses winforms created on various servers and then activated for remoting.  A client calls methods on these winforms. 

    All was fine until I added an asyncCallback.  That caused the problem mentioned in this thread. 

    Removing application.doevents() fixed the problem.

    Regards

    kc

    Sunday, February 26, 2006 3:28 PM
  • I've been working in a p2p application since January and have found no problem at all, but last week this exception stopped us.

    • I am using asyncronous socket operations to launch new threads every time a new message is received by the application and
    • I am making all Control (the class from System.Windows.Forms) method calls in a thread-safe manner, that is, using the Invoke method.
    • I am using try-catch in every possible way, however, the exception is kinda "jumpy"... there is no way to catch it.
    So, this exception is still there and I've found no solution in a week of work.

    What is the official way to post a bug-suspect in MSDN?
    Thursday, March 16, 2006 7:47 PM
  • Hi, same problem but using a remote server activate object.

    The solution works fine in .Net 1.1 but in 2.0 final returns System.InvalidOperationException ("The Undo operation encountered a context that is different from what was applied..."). And VS2005 shows me only "External Code" and no stack trace.

    static string GetOfferBookStatus()
    {

    OfferBook offerBook = (OfferBook)Activator.GetObject(typeof(OfferBook), "tcp://localhost:8090/OfferBookSubscribe");

    return offerBook.GetStatus();

    }

    private void cmdList2_Click(object sender, System.EventArgs e)
    {

    txtMessages.Text = (string)Invoke( new DelegateType(GetOfferBookStatus));

    }

     

    Alex

    Friday, March 31, 2006 3:59 PM
  • http://lab.msdn.microsoft.com/ProductFeedback/
    Friday, March 31, 2006 5:54 PM
  • Hi, same problem but using a remote server activate object.

    The solution works fine in .Net 1.1 but in 2.0 returns System.InvalidOperationException (The Undo operation encountered...) and VS2005 shows only "External Code" and no stock strace.

    The latest thing I'v tried was calling a method in a remote object using Invoke and Delegate:

    static string GetOfferBookStatus()
    {
        OfferBook offerBook = (OfferBook)Activator.GetObject(typeof(OfferBook), "tcp://localhost:8090/OfferBookSubscribe");

        return offerBook.GetStatus();
    }

    private void cmdList2_Click(object sender, System.EventArgs e)
    {
        txtMessages.Text = (string)Invoke( new DelegateType(GetOfferBookStatus));
    }

    But, doesn't matter if I set a property in a Windows.Form object (like in the example above) or set only a simple string variable: the InvalidOperationException always ocurrs.

    Please, any advice?!

    Alex

    Friday, March 31, 2006 7:55 PM
  • I could solve the problem only taking a completely different approach, this is, not using asyncronous socket operations directly invoking methods like beginreceive but using a thread that process al incoming packets and gets blocked in a receive method.
    Friday, March 31, 2006 8:00 PM
  • I am unfortunately having the same problem.  Made a thread in another one of the MSDN forums:

    http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=342756&SiteID=1&mode=1

    Has anyone been able to solve the problem, or at least come up with a good way to debug the issue?

    Edit: In the end, the solution ended up being to wrap calls to controls in .Invoke calls.  See the link above for more info

    Monday, April 10, 2006 5:59 PM
  • Hey Simon,

    Did you manage to find a solution for bring up a modal window.  I have a client activated remoting object that needs to get a password from the user.  Calling ShowDialog() kills everything with the error mentioned in this thread, however calling Show() will not crash the hosting process.  Obviously i need the processing of the method to stop until I get the password though.  I just cant get my head around this problem.

    If you have anymore info/workaround it would be greatly appreciated.

    Cheers,

    Duncan
    Wednesday, April 26, 2006 3:41 PM
  • e.g.

    System.Threading.Thread.Sleep(10);

    causes a context switch and all works fine.

    Thanks to Ruurd Boeke

     

     

    Monday, June 05, 2006 9:57 AM
  • I suspect yours is a simpler problem. When doing asynchronous I/O, or ANYTHING not on the one single main GUI thread, you have to marshal execution to the GUI thread when updating controls. This is threading 101.  My take on the problem is that you are doing aynchronous socket I/O, not touching the GUI, and I found it to be sensitive to the state of the current form. Such as when first loading, but before shown.
    Thursday, June 08, 2006 3:28 PM
  • I had a similar problem that was caused by blocking too long (due to waiting for user feedback through UI) in the socket's asynchronous callback.  The problem became evident when multiple callbacks methods were invoked before the previous ones finished.

    I would get the exception if the callbacks completed out-of-order (if the last one called on the stack was not the first to complete.)

    Pseudo-code:

    MyCallBack(AsyncResult result)
    {
    EndAcceptTcpClient(result);
    ProcessResult(); //blocks for a long time...
    }

    BeginAcceptTcpClient(..., MyCallback)


    As long as the ProcessResult() method completed before the next callback was invoked OR the callbacks were completed most recent-first (order the call was put on the stack, I'm guessing.) Everything was ok, otherwise the problem occurred.

    I guessed, from the error description, that the asynchronous mechanism behind-the-scenes was capturing some sort of execution context of the underlying handler, making the callback, then undo'ing it.  Once the callbacks were completed out-of-order there were issues because the undo didn't correspond to the expected capture.  Sounds like a bug in the asynchronous callback mechanism for sockets to me, but I digress...

    To fix it, I just spawned a thread to perform the work in ProcessResult().  This way, the callback returns immediatly, and the asynchronous call is complete.

    So my code looked something like:

    void ProcessResultHelper()
    {
    ProcessResult();
    }

    MyCallBack(AsyncResult result)
    {
    EndAcceptTcpClient(result);
    Thread t = new Thread(new ThreadStart(ProcessResultHelper));
    t.Start(); //spawn thread and
    } //exit method immediatly...

    BeginAcceptTcpClient(..., MyCallback)


    Code works fine now.  I would LOVE for someone who understands the internals of the socket callback mechanism to explain the exact cause.

    • Proposed as answer by Robin DS Sunday, July 05, 2009 4:02 PM
    Sunday, September 10, 2006 10:49 PM
  • I got this error when my code made reference to a property of the My.Settings object.

     

    The scenario was as follows:

     

    I have a multi-threaded socket server.

    One of the threads did some processing (including accessing the My.Settings object) and then further along, threw an exception when it tried to call a web-service.

    I handled the exception in a try block.

    After exiting the try block, the "Undo operation encountered..." error reared its ugly head.

     

    When I eliminated any references to the My.Settings object, that error went away.

     

    Hope that helps.

    Tuesday, April 03, 2007 10:31 PM
  • Hi Ruurd Boeke

    Can you please let me know how did you debug the problem ?

    Have you used any tools to get to the point where the problem occurred  ?

    I too face the same problem, but the OS does not give much information to debug the problem.

     

    Thanks

    Rama

    Monday, April 16, 2007 2:49 PM
  • I just had the same problem with a real simple object. I removed all references to My.Settings and the problem went away.
    Wednesday, July 18, 2007 1:45 PM
  • I had the same issue using a TCPClient.

    The fix was easier than I thought and made me want to break alot of things.....

    You have to force the context switch... easiest way of doing that back to the main ui...

    example on the Form Code

    Code Snippet

    Private Delegate Sub __AuthHandler(Byval userID As string,Byval pass As string)

    Private Sub AuthHandler(Byval userID As string,Byval pass As string)
    if invokeRequired() then
    'invoke the Form UI
    invoke(new __AuthHandler(addressOf AuthHandler),New Object() {userID,pass})
    Else
    'handle Authentication Code
    End if

    End Sub

    Public Sub onDataReceived(Byval Data As String)
    Dim info() As String = Data.split(",")
    AuthHandler(info(0).toString(),info(1).toString())
    End Sub



    Code Snippet

    'From your ClientConnection class

        Private Sub StreamReceiver(ByVal ar As IAsyncResult)
            Dim BytesRead As Integer
            Dim strMessage As String

            Try

                SyncLock client.GetStream
                    BytesRead = client.GetStream.EndRead(ar)
                End SyncLock

                strMessage = Encoding.ASCII.GetString(_readBuffer, 0, BytesRead)

                RaiseEvent LineReceived(strMessage) 'Raise Event and handle with OnDataReceive on Form UI

                SyncLock client.GetStream
                    client.GetStream.BeginRead(_readBuffer, 0, client.ReceiveBufferSize, AddressOf StreamReceiver, Nothing)
                End SyncLock

            Catch ex As Exception
                MsgBox(ex.Message.ToString())
            End Try
        End Sub



    • Proposed as answer by Vegeta4ss Tuesday, July 21, 2009 4:50 PM
    Monday, September 10, 2007 5:06 AM
  • حل جميع المشكلات المتعلقة بالموضوع موجودة هنا

    the solve for all this problems is here

    http://forums.microsoft.com/msdn/ShowPost.aspx?postid=2376082&siteid=1

    Wednesday, November 07, 2007 8:37 AM
  •  

    I had the same problem.  Just use a methodInvoker like wh in this example:

     

    Private Sub ProductResultsCallback(ByVal ar As IAsyncResult)

     

    Dim command As SqlCommand = CType(ar.AsyncState, SqlCommand)

    Dim reader As SqlDataReader = command.EndExecuteReader(ar)

    Dim dt As New DataTable

    dt.Load(reader)

     

    ' Here is the magic.

    Dim wh As New MethodInvoker(AddressOf White)

    Me.Invoke(wh)

     

    End Sub

     

    Private Sub White()

    ProductFields.BackColor = Color.White

    End Sub

    Friday, December 07, 2007 8:42 PM
  • Thanks.  Application.DoEvents() was the causing this error in my application too.
    Monday, February 18, 2008 5:12 PM
  • I also faced the same problem and found that the problem occurs while the context switching of the threads. I had a remoring server whcich call a delegate using BeginInvoke and I put a Application.DoEvents to wait for the IAsyncResult to complete. After a lot of googling and reading forums I erase the DoEvents part and it started working perfect.

     

    I have also seen the UI related examples of this problem in this forum; So the basic cause is when you leave the current thread and start doing task on another thread. Once the delegate is done with its work , it tries to come back to the thread from where it was called and there it throws the exception. So the solution is either leave the thread for ever ( asynchronous callback) or wait for the completion if badly needed (as I did).

    Wednesday, May 28, 2008 2:11 PM
  • I just created a new thread and ran my delegate function from the new thread.

    I was running this code from a BeginReceive function:

            1. ) Dim f As Form1 = My.Application.OpenForms("Form1")
            2. ) f.Invoke(New ChangeIconHandler(AddressOf f.ChangeIcon), _
            3. ) New Object() {param})

    I would receive the error on line 1.

    To solve the issue for me I created a new Sub and called the Sub from a new thread.  Calling the delegate from that sub on a new thread solved everything.

    Put this code at the top of my class: (put my code inside a Sub)
    Private Sub ChangeIco(ByVal param As Integer)
            Dim f As Form1 = My.Application.OpenForms("Form1")
            f.Invoke(New ChangeIconHandler(AddressOf f.ChangeIcon), _
                     New Object() {param})
    End Sub
    In-place of my other code i put: (called sub from a new thread)
    Dim t As New Thread(AddressOf ChangeIco)
    t.Start(2)

    ----------------


    Solved my problem. Hope it helps somebody.

    -Sean

    • Proposed as answer by MyNameIsSean Wednesday, July 09, 2008 6:34 PM
    Wednesday, July 09, 2008 6:32 PM
  • Please please MS, suggest a proper workaround for this ongoing bug.

    It is very very easy to re-create.

    My scenario.


    Server app
    Client app

    The client app establishes a tcp channel tot he server.

    I open a master form diaplaying a list of markets

    I select a market which opens a new market form

     The code for communicating with the server is thus;

    Public Delegate Function GCMPCDelegate(ByVal pMarketID As Integer) As Object

    Private RemoteCallbackGCMPC As AsyncCallback

    Private RemoteDelegateGCMPC As GCMPCDelegate

    Private obj As myInterface



    RemoteCallbackGCMPC = New AsyncCallback(AddressOf OurRemoteAsyncCallbackGCMPC)

    RemoteDelegateGCMPC = New GCMPCDelegate(AddressOf obj.GCMPC)

    Public e As ManualResetEvent


    Private Sub UseServer()

    e = New ManualResetEvent(False)

    RemoteDelegateGCMPC.BeginInvoke(mMarket.MarketID, RemoteCallbackGCMPC, Nothing)

    End Sub

    Public Sub OurRemoteAsyncCallbackGCMPC(ByVal ar As IAsyncResult)

    Dim delGCMPC As GCMPCDelegate = CType(ar, AsyncResult).AsyncDelegate

    mCtlAsync.GenUMP(delGCMPC.EndInvoke(ar))

    DataDone(mMarket.MarketID)

    e.Set()

    End Sub

    The server is simply retrieving data from the internet and passing to the client.

    All works fine for until the market form is closed and new one(s) opened a few times and this error pops up at random.

    I have tried all the suggestions posted here and elsewhere to no avail. I suspect that an old callback is trying to connect to the new market instance somehow.


    Thursday, March 19, 2009 11:19 AM
  • I had the same exception too, and Brian_K's solution resolved it.

    My code worked like this:
    •  A TcpListener starts, and I call the BeginAcceptTcpClient method
    • Inside that method in a try-catch structure the EndAcceptTcpClient method is called; After that, I invoked a method (I called it AddEntry ) that adds an item to a listbox not created in this thread.

    This raised the exception.

    The fix: I didn't invoke the method on the thread of the asynchronous AcceptTcpClient callback, but created a new thread that would invoke AddEntry like Brian_K applied in his code. The exception hasn't occured since.

    I also have no idea how the asynchronous TCP-operations work but I wouldn't start throwing accusations at the .NET framework; In my detailed exception report I noticed that the TCP-operations rely on mscorlib.dll, the same dll for example IE uses to handle it's communication. If you want to know how the TCP mechanisms work look for information about TCP in general. I think you'll find more explanation there then in the .NET manuals
    • Edited by Robin DS Sunday, July 05, 2009 4:18 PM
    Sunday, July 05, 2009 4:12 PM
  • I had the same issue using a TCPClient.

    The fix was easier than I thought and made me want to break alot of things.....

    You have to force the context switch... easiest way of doing that back to the main ui...

    example on the Form Code

    Code Snippet

     

    Private Delegate Sub __AuthHandler(Byval userID As string,Byval pass As string)

    Private Sub AuthHandler(Byval userID As string,Byval pass As string)
    if invokeRequired() then
    'invoke the Form UI
    invoke(new __AuthHandler(addressOf AuthHandler),New Object() {userID,pass})
    Else
    'handle Authentication Code
    End if

    End Sub

    Public Sub onDataReceived(Byval Data As String)
    Dim info() As String = Data.split(",")
    AuthHandler(info(0).toString(),info(1).toString())
    End Sub



    Code Snippet

    'From your ClientConnection class

        Private Sub StreamReceiver(ByVal ar As IAsyncResult)
            Dim BytesRead As Integer
            Dim strMessage As String

            Try

                SyncLock client.GetStream
                    BytesRead = client.GetStream.EndRead(ar)
                End SyncLock

                strMessage = Encoding.ASCII.GetString(_readBuffer, 0, BytesRead)

                RaiseEvent LineReceived(strMessage) 'Raise Event and handle with OnDataReceive on Form UI

                SyncLock client.GetStream
                    client.GetStream.BeginRead(_readBuffer, 0, client.ReceiveBufferSize, AddressOf StreamReceiver, Nothing)
                End SyncLock

            Catch ex As Exception
                MsgBox(ex.Message.ToString())
            End Try
        End Sub



    This worked for me.  Inside of my event that caused the "Undo" exception I had no calls to any "my.settings", "application.doevents()", or even any updates to controls. 

    I guess that raising an event on a async thread and then handling that event on the UI thread is what my problem was. I was always under the impression that you can raise events from other threads as long as you did not try and do updates to the controls.  I was just updating totals and building a string and returning it back through the open socket. ...Guess I learned something. Even though I still don't totally understand why.
    Tuesday, July 21, 2009 4:55 PM
  • I had the same issue. After googling I ve find out this is definitely an .net framework bug.

    Will Updating dot net framework resolve this issue?? i.e using .net framework 3.0 or 3.5?
    Monday, September 28, 2009 12:23 PM
  • I had the same issue. After googling I ve find out this is definitely an .net framework bug.

    Will Updating dot net framework resolve this issue?? i.e using .net framework 3.0 or 3.5?
    Monday, September 28, 2009 12:23 PM
  • I too had this issue, the cause is that you're accessing the Application object on a thread other than the thread it was created on. The solution is to invoke a method onto the thread that created the Application object (or the owner). Like such:

    VB.NET:
    Private Sub CheckVersion(ByVal Version As String)
        Dim ver As String = GetVersion()
        If (Version <> ver) Then
            Update("http://someurl")
        End If
    End Sub
    
    Delegate Function dGetVersion() As String
    Private Function GetVersion() As String
        If Owner.InvokeRequired Then
            Return Owner.Invoke(New dGetVersion(AddressOf GetVersion))
        Else
            Return My.Application.Info.Version.Major.ToString() + "." + My.Application.Info.Version.Minor.ToString() + "." + My.Application.Info.Version.Build.ToString() + "." + My.Application.Info.Version.Revision.ToString()
        End If
    End Function

    C# .NET:
    private void CheckVersion(string Version)
    {
        string ver = GetVersion();
        if ((Version != ver)) {
            Update("http://someurl");
        }
    }
    
    
    delegate string dGetVersion();
    private string GetVersion()
    {
        if (Owner.InvokeRequired) {
            return Owner.Invoke(new dGetVersion(GetVersion));
        }
        else {
            return My.Application.Info.Version.Major.ToString() + "." + My.Application.Info.Version.Minor.ToString() + "." + My.Application.Info.Version.Build.ToString() + "." + My.Application.Info.Version.Revision.ToString();
        }
    }
    

    Also, this error should only show up in the debugger. I believe there is a setting to make it stop showing up in the debugger, however it's better to fix the underlying issue, as there's a reason the debugger complains about it ;).
    Tuesday, October 27, 2009 12:44 PM
  • One of our user got this exception today. This is a WPF application and user took a mouse down action. it happened just after OnPreviewMouseDown. It is non reproducable, so not sure what is causing this.

    Unhandled exception occured, Exception='System.InvalidOperationException: The Undo operation encountered a context that is different from what was applied in the corresponding Set operation. The possible cause is that a context was Set on the thread and not reverted(undone).
    at System.Threading.SynchronizationContextSwitcher.Undo()
    at System.Threading.ExecutionContextSwitcher.Undo()
    at System.Threading.ExecutionContext.runFinallyCode(Object userData, Boolean exceptionThrown)
    at System.Runtime.CompilerServices.RuntimeHelpers.ExecuteBackoutCodeHelper(Object backoutCode, Object userData, Boolean exceptionThrown)
    at System.Runtime.CompilerServices.RuntimeHelpers.ExecuteCodeWithGuaranteedCleanup(TryCode code, CleanupCode backoutCode, Object userData)
    at System.Threading.ExecutionContext.RunInternal(ExecutionContext executionContext, ContextCallback callback, Object state)
    at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state)
    at System.Windows.Threading.DispatcherOperation.Invoke()
    at System.Windows.Threading.Dispatcher.ProcessQueue()
    at System.Windows.Threading.Dispatcher.WndProcHook(IntPtr hwnd, Int32 msg, IntPtr wParam, IntPtr lParam, Boolean& handled)
    at MS.Win32.HwndWrapper.WndProc(IntPtr hwnd, Int32 msg, IntPtr wParam, IntPtr lParam, Boolean& handled)
    at MS.Win32.HwndSubclass.DispatcherCallbackOperation(Object o)
    at System.Windows.Threading.ExceptionWrapper.InternalRealCall(Delegate callback, Object args, Boolean isSingleParameter)
    at System.Windows.Threading.ExceptionWrapper.TryCatchWhen(Object source, Delegate callback, Object args, Boolean isSingleParameter, Delegate catchHandler)'
    Friday, December 03, 2010 6:17 AM