none
.NET Crash after recent updates (Win7 64bit) RRS feed

  • Question

  • We are getting a number of users experiencing a crash in our program after installing recent updates (we are unable to reproduce on test machines - but have access to one of our customers machines). The program uses .NET 2.0.

    Machines are Windows 7 64bit (user machines) with all recent updates.
    Logged in as Admin and tried different UAC settings

    System.TypeInitializationException: The type initializer for 'PayAtPC.MM' threw an exception. ---> System.IO.FileNotFoundException: The specified module could not be found. (Exception from HRESULT: 0x8007007E)
       at System.Management.ThreadDispatch.Start()
       at System.Management.ManagementScope.Initialize()
       at System.Management.ManagementObjectSearcher.Initialize()
       at System.Management.ManagementObjectSearcher.Get()
       at Microsoft.VisualBasic.Devices.ComputerInfo.get_OSManagementBaseObject()
       at Microsoft.VisualBasic.Devices.ComputerInfo.get_OSFullName()
       at PayAtPC.MM..cctor()
       --- End of inner exception stack trace ---

    Re-installed .NET 4 - no problems or erros

    Ran the .NET Verification Tool - all .NETs appear to be installed and working correctly

    Ran the WMI Diagnosis Utility - appear some modules are (now?) missing. Not sure if this is part of the problem, but simply do not know how to fix.

    Tried to repair permissions as well (didn't see any problems). The results are at this link
    https://dl.dropbox.com/u/2074226/amsi/wmidiag_blaine1_01.zip

    Any help be greatly appreciated.

    Thanks

    Blaine

    Some extra info in the error outside the inner exception

       at System.Windows.Forms.Control.OnLostFocus(EventArgs e)
       at System.Windows.Forms.Control.WmKillFocus(Message& m)
       at System.Windows.Forms.Control.WndProc(Message& m)
       at System.Windows.Forms.ScrollableControl.WndProc(Message& m)
       at System.Windows.Forms.ContainerControl.WndProc(Message& m)
       at System.Windows.Forms.Form.WndProc(Message& m)
       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)


    ************** Loaded Assemblies **************
    mscorlib
        Assembly Version: 2.0.0.0
        Win32 Version: 2.0.50727.5456 (Win7SP1GDR.050727-5400)
        CodeBase: file:///C:/Windows/Microsoft.NET/Framework/v2.0.50727/mscorlib.dll
    ----------------------------------------
    PayAtPC
        Assembly Version: 2.5.1017.1001
        Win32 Version: 2.05.1017.1001
        CodeBase: file:///C:/Program%20Files%20(x86)/PAY@PC/PayAtPC.exe
    ----------------------------------------
    Microsoft.VisualBasic
        Assembly Version: 8.0.0.0
        Win32 Version: 8.0.50727.5420 (Win7SP1.050727-5400)
        CodeBase: file:///C:/Windows/assembly/GAC_MSIL/Microsoft.VisualBasic/8.0.0.0__b03f5f7f11d50a3a/Microsoft.VisualBasic.dll
    ----------------------------------------
    System
        Assembly Version: 2.0.0.0
        Win32 Version: 2.0.50727.5456 (Win7SP1GDR.050727-5400)
        CodeBase: file:///C:/Windows/assembly/GAC_MSIL/System/2.0.0.0__b77a5c561934e089/System.dll
    ----------------------------------------
    System.Windows.Forms
        Assembly Version: 2.0.0.0
        Win32 Version: 2.0.50727.5460 (Win7SP1GDR.050727-5400)
        CodeBase: file:///C:/Windows/assembly/GAC_MSIL/System.Windows.Forms/2.0.0.0__b77a5c561934e089/System.Windows.Forms.dll
    ----------------------------------------
    System.Drawing
        Assembly Version: 2.0.0.0
        Win32 Version: 2.0.50727.5462 (Win7SP1GDR.050727-5400)
        CodeBase: file:///C:/Windows/assembly/GAC_MSIL/System.Drawing/2.0.0.0__b03f5f7f11d50a3a/System.Drawing.dll
    ----------------------------------------
    System.Runtime.Remoting
        Assembly Version: 2.0.0.0
        Win32 Version: 2.0.50727.5420 (Win7SP1.050727-5400)
        CodeBase: file:///C:/Windows/assembly/GAC_MSIL/System.Runtime.Remoting/2.0.0.0__b77a5c561934e089/System.Runtime.Remoting.dll
    ----------------------------------------
    System.Configuration
        Assembly Version: 2.0.0.0
        Win32 Version: 2.0.50727.5420 (Win7SP1.050727-5400)
        CodeBase: file:///C:/Windows/assembly/GAC_MSIL/System.Configuration/2.0.0.0__b03f5f7f11d50a3a/System.Configuration.dll
    ----------------------------------------
    System.Xml
        Assembly Version: 2.0.0.0
        Win32 Version: 2.0.50727.5420 (Win7SP1.050727-5400)
        CodeBase: file:///C:/Windows/assembly/GAC_MSIL/System.Xml/2.0.0.0__b77a5c561934e089/System.Xml.dll
    ----------------------------------------
    System.Management
        Assembly Version: 2.0.0.0
        Win32 Version: 2.0.50727.5420 (Win7SP1.050727-5400)
        CodeBase: file:///C:/Windows/assembly/GAC_MSIL/System.Management/2.0.0.0__b03f5f7f11d50a3a/System.Management.dll
    ----------------------------------------



    Tuesday, July 31, 2012 5:48 PM

Answers

All replies

  • Hi Blaine,

    Thank you for posting on this forum.

    Generally, we need the details steps to reproduce this scenario. 

    You have mentioned that you can fix this issue by re-install .net framework, so please try this action on all the other crashed machines.

    In addition, based on the exception stack, the exception occurs in the "PayAtPC.MM", so please check the constructor again to verify every step is correct.

    Best regards,


    Mike Feng
    MSDN Community Support | Feedback to us
    Please remember to mark the replies as answers if they help and unmark them if they provide no help.

    Wednesday, August 1, 2012 8:35 AM
    Moderator
  • 1. You have mentioned that you can fix this issue by re-install .net framework
    Sorry for misunderstanding - no this is not correct. There are no errors during the installation of the .NET 4 runtime (it can uninstall and reinstall). But of course this does not fix the problem.

    2. Generally, we need the details steps to reproduce this scenario
    Very simple.
    Double click the PayAtPC shortcut on the desktop (that was working before the Windows 7 Updates) - the software starts and works.
    Double click the PayAtPC shortcut on the desktop (after Updates) - the software generates the error shown.

    3. 
    please check the constructor again to verify every step is correct
    I don't understand what you mean.

    Based on the exception, there is something missing (something that broke) after updates.
    Something related to 
    System.Management

    Here is another example (from another customer yesterday that reported this as a new problem, FYI - software was working previously since it was first installed ~ 6 months).

    Uninstall/reinstall PayAtPC does not fix the problem
    Uninstall/reinstall .NET Framework does not fix the problem

    We are thinking it is a permissions issue or the update some how destroyed a DLL (something related to the System Management DLLs) , or even a change in permissions? 
    It does appear that the system is missing WMI Files since the update. We've tried different steps to re-register the DLLs but the system says they are missing. We are not sure how to repair this and simply do not know how to resolve.

    As you can see, our problem is similar to what was reported here for others in Vista
    http://windowsxp.mvps.org/repairwmi.htm

    Are there any solutions or suggestions on how we can resolve this with Windows 7 and recent updates?


    Regards, Blaine

    Wednesday, August 1, 2012 1:34 PM
  • Hi Blaine,

    >>2. Generally, we need the details steps to reproduce this scenario

    I mean on my side. I need to reproduce it on my side.

    >>3. please check the constructor again to verify every step is correct 

    I mean you need to check which line statement it crashed on, then you will find what reference this statement rely on, this may lead you to the issue DLL/component.

    >>As you can see, our problem is similar to what was reported here for others in Vista
    http://windowsxp.mvps.org/repairwmi.htm

    This link shows a fix about Microsoft WMI, but your issue is about your own application.

    Best regards,


    Mike Feng
    MSDN Community Support | Feedback to us
    Please remember to mark the replies as answers if they help and unmark them if they provide no help.

    Thursday, August 2, 2012 6:03 AM
    Moderator
  • Okay. I guess there is something going on that I don't understand.

    >>2:  mean on my side. I need to reproduce it on my side.
    I don't think this is possible. We've had about 10 users out of 500-600 that got this error. But we are unable to reproduce it in-house.

    >>3:  
    It doesn't crash on any line, that is the problem. The program cashes before any code is executed.

    We will keep trying to investigate the problem.



    Regards, Blaine

    Friday, August 3, 2012 12:49 AM
  • Hi Blaine,

    >>I don't think this is possible. We've had about 10 users out of 500-600 that got this error. But we are unable to reproduce it in-house.

    If so, you can try this analysis tool: http://social.technet.microsoft.com/wiki/contents/articles/8103.application-crash-dump-analysis-windows-7.aspx 

    http://blogs.technet.com/b/askperf/archive/2007/06/15/capturing-application-crash-dumps.aspx 

    I hope this will be helpful.

    Best regards,


    Mike Feng
    MSDN Community Support | Feedback to us
    Please remember to mark the replies as answers if they help and unmark them if they provide no help.

    Friday, August 3, 2012 1:51 AM
    Moderator
  • TypeInitializers are evil, because if you do anything more complicated you may easily create a circular reference between them and end up with weird errors that depend on timing, call order and other stuff. Debugging such errors is typically extremely hard. Such error might be there forever and recent .NET Framework fix might have just exposed them.

    Moreover the inner exception will not create a crash dump. You need either live debugging of the app - look at all first-chance exceptions, or you can try to think hard about PayAtPC.MM type initializer code, or you can wrap its code in try-catch and report the exception into a specific log and ask your customer to run it. Neither of them is easy option ...

    -Karel

    Thursday, August 9, 2012 4:49 AM
    Moderator