none
Weird Exception C015000F in 32bit MFC app on 64 bit windows 7 with SQLCE 3.5 SP2 RRS feed

  • Question

  • Exception code: C015000F The activation context being deactivated is not the
    most recently activated one.
    Fault address: 776F4391 01:00074391 C:\Windows\SysWOW64\ntdll.dll
     
    One of my customers is getting the following error apparently when trying to
    update an SQLCE 3.5 SP2 database.
    It appears that the correct 32 and 64 bit versions of Sp2 are installed on
    his machine.
     
    Unfortunately, on the 64 bit w7 machine I have, the error doesn't occur.
     
    I've tracked this down to possibly being related to this hotfix:
    http://support.microsoft.com/kb/976038
     
    described more fully here:
    http://blog.paulbetts.org/index.php/2010/07/20/the-case-of-the-disappearing-onload-exception-user-mode-callback-exceptions-in-x64/Has anyone else run across this. Any obvious reasons SQLCE might throw anexception on one machine but not another? I have a copy of the databasethat was being accessed, but it appears fine.--Anthony WieserWieser Software Ltd
     

    Anthony Wieser | Wieser Software Ltd | www.wieser-software.com
    Wednesday, October 20, 2010 11:53 AM

Answers

  • It wasn't SQL CE!
    It turned out it was a problem incorrectly decoding a LVN_GETDISPINFO notification.
     
    For some reason one particular machine was asking for LVN_GETDISPINFO without the LVIF_TEXT flag set, and passed a NULL pszText buffer.
    When I filled it in, it caused my program to copy into a null buffer.
    Because it was a transition from 64 bit to 32 bit to get the buffer, the exception was swallowed, and ignored, until the hotfix mentioned in the prior post was applied (again here):
     
    Once the hotfix was applied, it was possible to see that a NULL buffer was being passed in.
     
    Hope this info helps someone else, even if it's not in the correct group...
     
    Anthony Wieser
    Wieser Software Ltd
     
     
     
    "Anthony Wieser" wrote in message news:78522a22-c8ab-4904-967e-137a99222fc1...
    They are the exact same version (as reported in add/remove programs anyway)
     
    I think what might actually be happening is the code is throwing an exception because of an error (auto number key integrity I'm guessing now), but is swallowing it and taking the process down on 64 bit machines instead of failing where it actually occurs.
     
    Anthony Wieser
    Wieser Software Ltd
     
    "ErikEJ" wrote in message news:3f2181c6-dac3-4bcf-9e04-bd8c2ed728b7...

    Hi Anthony,

    Make sure that the x86 and x64 versions of SQL Server Compact are excatly the same build number.


    Visit my SQL Compact blog - http://erikej.blogspot.com - Please mark as answer, if this was it.

    Anthony Wieser | Wieser Software Ltd | www.wieser-software.com

    Anthony Wieser | Wieser Software Ltd | www.wieser-software.com
    Monday, October 25, 2010 4:26 PM

All replies

  • Hi Anthony,

    Make sure that the x86 and x64 versions of SQL Server Compact are excatly the same build number.


    Visit my SQL Compact blog - http://erikej.blogspot.com - Please mark as answer, if this was it.
    Wednesday, October 20, 2010 4:11 PM
    Moderator
  • They are the exact same version (as reported in add/remove programs anyway)
     
    I think what might actually be happening is the code is throwing an exception because of an error (auto number key integrity I'm guessing now), but is swallowing it and taking the process down on 64 bit machines instead of failing where it actually occurs.
     
    Anthony Wieser
    Wieser Software Ltd
     
    "ErikEJ" wrote in message news:3f2181c6-dac3-4bcf-9e04-bd8c2ed728b7...

    Hi Anthony,

    Make sure that the x86 and x64 versions of SQL Server Compact are excatly the same build number.


    Visit my SQL Compact blog - http://erikej.blogspot.com - Please mark as answer, if this was it.

    Anthony Wieser | Wieser Software Ltd | www.wieser-software.com
    Thursday, October 21, 2010 4:19 PM
  • It wasn't SQL CE!
    It turned out it was a problem incorrectly decoding a LVN_GETDISPINFO notification.
     
    For some reason one particular machine was asking for LVN_GETDISPINFO without the LVIF_TEXT flag set, and passed a NULL pszText buffer.
    When I filled it in, it caused my program to copy into a null buffer.
    Because it was a transition from 64 bit to 32 bit to get the buffer, the exception was swallowed, and ignored, until the hotfix mentioned in the prior post was applied (again here):
     
    Once the hotfix was applied, it was possible to see that a NULL buffer was being passed in.
     
    Hope this info helps someone else, even if it's not in the correct group...
     
    Anthony Wieser
    Wieser Software Ltd
     
     
     
    "Anthony Wieser" wrote in message news:78522a22-c8ab-4904-967e-137a99222fc1...
    They are the exact same version (as reported in add/remove programs anyway)
     
    I think what might actually be happening is the code is throwing an exception because of an error (auto number key integrity I'm guessing now), but is swallowing it and taking the process down on 64 bit machines instead of failing where it actually occurs.
     
    Anthony Wieser
    Wieser Software Ltd
     
    "ErikEJ" wrote in message news:3f2181c6-dac3-4bcf-9e04-bd8c2ed728b7...

    Hi Anthony,

    Make sure that the x86 and x64 versions of SQL Server Compact are excatly the same build number.


    Visit my SQL Compact blog - http://erikej.blogspot.com - Please mark as answer, if this was it.

    Anthony Wieser | Wieser Software Ltd | www.wieser-software.com

    Anthony Wieser | Wieser Software Ltd | www.wieser-software.com
    Monday, October 25, 2010 4:26 PM
  • It is a hard life being a C++ programmer :-)
    Visit my SQL Compact blog - http://erikej.blogspot.com - Please mark as answer, if this was it.
    Monday, October 25, 2010 4:49 PM
    Moderator