none
AccessViolationException when reading Properties.Settings.Default field. .NET 4.0, C#, VS10 RRS feed

  • Question

  • I am having an issue with reading a specific property from Properties.Settings.Default. The first time I run this code during a debug session, it is successful. The second time it is run, I get an AccessViolationException. This exception only happens when I get the VersionMajor property of Properties.Settings.Default, but not the VersionMinor property.

     

                byte[] tmparray;
                byte[] message = new byte[599];
                int i = 0;
    
                message[i++] = 16; //write multiple registers
                message[i++] = 0; //high byte of address
                message[i++] = 98; //low byte of address
                message[i++] = 1; //high byte of register count
                message[i++] = 40; //low byte of register count
                message[i++] = 0; //reserved
                message[i++] = Properties.Settings.Default.VersionMajor; //major version number
                message[i++] = Properties.Settings.Default.VersionMinor; //minor version number
    

     

    Both properties are of the byte type. Any insight into the cause of this issue would be very beneficial.

    Thanks


    Wednesday, September 14, 2011 8:57 PM

Answers

  • I solved the problem. Later in the application, I was calling down to a custom API in a .dll file which has unmanaged code.This API has a buffer overflow bug.  Then, this code is run again, and the data was corrupted.  As a test, I temporarily increased my array from 599 to 606 bytes, and my code now executes perfectly. I will have to update the API to account for this.
    Thursday, September 15, 2011 5:30 PM

All replies

  • A byte ranges from 0 to 255, does the value of Properties.Settings.Default.VersionMajor exceed this range?

    What's the call stack of this AV exception? what if you use a literal integer number to replace the Properties.Settings.Default.VersionMajor ?


    Eric Yang [MSFT]
    MSDN Community Support | Feedback to us
    Get or Request Code Sample from Microsoft
    Please remember to mark the replies as answers if they help and unmark them if they provide no help.

    • Edited by eryang Thursday, September 15, 2011 6:49 AM
    Thursday, September 15, 2011 6:47 AM
  • The initial value of Properties.Settings.Default.VersionMajor is 0x01, and is set as an application level byte property. I attempted to add a watch to it, but it seemed to go out of scope once my method returned. The watch returns the following exception:

    'System.Windows.Forms.PropertyStore' does not contain a definition for 'Settings' and no extension method 'Settings' accepting a first argument of type 'System.Windows.Forms.PropertyStore' could be found (are you missing a using directive or an assembly reference?)

    The watch on Properties.Settings.Default.VersionMinor returns the same exception outside the method, but when back in the method it shows a value of 0x01, while VersionMajor throws the AV exception.

     

    The stack trace of the AV exception is:

       at System.Windows.Forms.UnsafeNativeMethods.DispatchMessageW(MSG& msg)

       at System.Windows.Forms.Application.ComponentManager.System.Windows.Forms.UnsafeNativeMethods.IMsoComponentManager.FPushMessageLoop(IntPtr dwComponentID, Int32 reason, Int32 pvLoopData)

       at System.Windows.Forms.Application.ThreadContext.RunMessageLoopInner(Int32 reason, ApplicationContext context)

       at System.Windows.Forms.Application.ThreadContext.RunMessageLoop(Int32 reason, ApplicationContext context)

       at System.Windows.Forms.Application.Run(Form mainForm)

       at IO_Multiplexer_Config.Program.Main() in D:\My Projects\Custom Products\Development\Josh\Frequentis\Windows Client\IO Multiplexer Config\Program.cs:line 55

     

    This stack trace doesn't make any sense to me.

    Thursday, September 15, 2011 1:19 PM
  • I solved the problem. Later in the application, I was calling down to a custom API in a .dll file which has unmanaged code.This API has a buffer overflow bug.  Then, this code is run again, and the data was corrupted.  As a test, I temporarily increased my array from 599 to 606 bytes, and my code now executes perfectly. I will have to update the API to account for this.
    Thursday, September 15, 2011 5:30 PM