AccessViolationException in Excel 2010 but not 2007 on Range.Insert method RRS feed

  • Question

  • I have a VSTO 2010 document-level Excel project that is meant to run in Excel 2007 and 2010. It works perfectly in Excel 2007 but is extremely flaky in 2010. I get an AccessViolationException on a Range.Insert call.  One of the lines of code that causes this type of exception is:

    scheduleRange.Resize(, (scheduleLength) - 1).Offset(, scheduleLength
    + 1).Insert(Excel.XlInsertShiftDirection.xlShiftToRight)

    Certainly nothing complex and prior to this line I’m calling the same methods off the same object several times – offset, resize, insert.  It doesn’t fail until it reaches the line above which makes me think it actually has nothing to do with the line above.  And, when it fails the scheduleRange object is a valid range ($AG:$AT) and the offset and resize methods adjust that to a valid range as well ($AT:$BD).

    And to add insult to injury the code behaved differently for ONE build when I switched the order of the Resize and Offset calls but the next time it ran the exception occurred again.  What is going on????

    Maybe it is worth noting that the exception occurs on an x64 Windows 7 Pro dev virtual machine with Office 2010 installed but not on another x64 Windows 7 Pro dev virtual machine with Office 2007 installed.  And when deployed it behaves the same way – works with Excel 2007 but not in 2010.

    Friday, June 24, 2011 2:43 AM

All replies

  • Hi Robert,


    Thanks for your post.


    1.       Office solution is version sensitive, which means that it is difficult to develop an Office solution for both 2007 & 2010.

    2.       Office 2010 includes 32-bit version and 64-bit two versions. If you compile your solution targeting at x86 CPU and then deploy in 64-bit Office. It will definitely fail to work. The same thing will happen if you create the solution targeting at x64 CPU and deploy in 32-bit Office. So I would recommend you to target at Any CPU when you develop Office solution, especially Office 2010.

    3.       Like I have said previous, it is difficult to create an Office solution for multiple versions Office. However, it is not impossible (though it is not recommended). If you are interesting in this, please have a look at the documents below:


    I hope this helps

    Best Regards, Calvin Gao [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.

    Tuesday, June 28, 2011 6:52 AM
  • Once again, thanks for the response Calvin.  But…

    First, the project is not an add-in.  As I stated, it is a document-level project.  All the posts you referenced are related to add-ins.

    Second, the solution is targeting Any CPU.  I don’t think this is an issue with x64 vs. x86 because the app loads without issue and some of the features work fine.  This seems to be a difference between Excel 2003/2007 and Excel 2010.

    Let me offer some more details…

    The original solution was a Visual Studio 2008 / VSTO 2005 SE project that worked in Excel 2003/2007.  The client wants to upgrade to Excel 2010 which means VSTO 2005 SE is not an option so I upgraded the project to Visual Studio 2010 / VSTO 2010 and got it working with Excel 2007.  I then experienced issues after deployment when opening the workbook in Excel 2010.  So, I migrated the solution to another development image that has Visual Studio 2010 / VSTO 2010 and Office 2010 installed (as required, I keep a separate development image for each version of Office).  But, I’m experiencing the same issues in the project that specifically targets a 2010 workbook.  And the failure doesn’t always occur on the same line of code.  Sometimes I don’t experience a failure in the same method two times in a row.  And when the app is deployed it becomes even more flaky – working once then not working the next time the app is run.

    With regard to supporting multiple Office versions – I’ve done this numerous times with Excel 2003/2007.  I’ve used the same project to support both versions.  If there are now differences between Excel 2007 and 2010 then Microsoft has really taken a turn for the worse.  It is ludicrous to prevent a single VSTO 2010 project from working in both Excel 2007 and 2010 especially when I’m not doing anything that both versions shouldn’t be capable of.  The code that is giving me fits in 2010 is simply inserting columns using a range object.  That certainly is something that should work regardless of the Excel version.

    Tuesday, June 28, 2011 11:13 PM
  • Hi Robert,


    Thanks for your update.


    Would you like to elaborate how you migrate Office 2007 solution to Office 2010? You can see in this document:

    Upgrading and Migrating Office Solutions

    So when you migrate your 2007 solution to 2010, Visual studio will modify the solution to target the Office version you have installed, which means that the PIA reference change from 12.0 version to 14.0 version.

    Under most situations, the solution will work well. However, if the solution call some methods or object models which are change in Office 2010, the solution will throw some unexpected exceptions. You should try to check if you have used this kind of methods.

    Object Model Changes Since Microsoft Office 2007


    I hope this helps.

    Best Regards, Calvin Gao [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.

    Wednesday, June 29, 2011 9:03 AM
  • Let’s not even focus on the conversion/migration because that succeeded.  The bottom line is – I have a VSTO 2010 project that targets Excel 2010 and references version 14 of the PIAs.  I am getting flaky behavior and AccessViolationExceptions on simple and oft-used methods like Range.Insert.  I’m not using the methods or properties in the list of changes to the object model.

    I’m not going to get an answer to the issue in this forum.  I’ve contacted Microsoft technical support and will proceed with them.  I’ll post a response to this thread once the issue is determined.

    Wednesday, June 29, 2011 8:14 PM