This problem has just become a bigger deal where I work. Maybe those of us
that have experienced this problem could put our heads together to try to
figure out what we are doing in common that is causing this to happen.
During database upgrades, we connect to an existing database, run 3-4 sql
strings, and approximately 100 sql scripts (loaded from binary references)
that total about 1.2 MB in size. This happens with much greater consistency
on the upgrade and almost never on a new install where we create the
database.
Dana
On 11/29/06, Rob Mensching <[EMAIL PROTECTED] > wrote:
Based on previous reports, I believe that there is a bug in the SQL
CustomActions that has been near impossible to track down where somewhere
memory gets corrupted and causes the CustomAction to crash. You see leaked
handles because MSI catches the exception and tells you that your code did
not clean up correctly (duh, it crashed).
I've never seen a consistent repro and never under a debugger. Normally
it was failing like 5% so your 50% is amazing. You might try using
pageheap/gflags + a debugger. Pageheap may force the crash even when the
debugger normally hides it. You also **might** try adding a bunch more
logging statements to the code to try and narrow down how far the code gets
before crashing. At the moment there is a lot of code that could be causing
the problem.
Killing this bug would be very, very good.
*From:* [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
*On Behalf Of *Dana Gutride
*Sent:* Wednesday, November 29, 2006 05:40
*To:* wix-users@lists.sourceforge.net
*Subject:* Re: [WiX-users] ConfigureSQL Bug
I have also noticed this bug. Oddly enough it is happening during an
upgrade only. During our initial install when we create the database, this
doesn't happen. During the upgrade, the user can select the database to
upgrade, 10-15 SqlScripts are all run against it and I see the same error.
It is tough to track down because it does happen periodically, and a reboot
almost always clears the problem up.
Dana
On 11/29/06, *Michael Osmond* <[EMAIL PROTECTED]> wrote:
Hello Rob and All,
I have a sort of reproducible case of ConfigureSql MSIHandle leaking
error. I understand this one has not been found
The error shows up as the following log output:
MSI (s) (BC:48) [10:05:24:840]: Doing action: ConfigureSql
Action 10:05:24: ConfigureSql. Configuring SQL Server
Action start 10:05:24: ConfigureSql.
MSI (s) (BC:6C) [10:05:24:900]: Invoking remote custom action. DLL:
C:\WINDOWS\Installer\MSI48.tmp, Entrypoint: ConfigureSql
MSI (s) (BC:6C) [10:05:25:593]: Leaked MSIHANDLE (393) of type 790531
for thread 1228
MSI (s) (BC:6C) [10:05:25:593]: Leaked MSIHANDLE (392) of type 790531
for thread 1228
MSI (s) (BC:6C) [10:05:25:593]: Leaked MSIHANDLE (381) of type 790540
for thread 1228
MSI (s) (BC:6C) [10:05:25:593]: Leaked MSIHANDLE (380) of type 790540
for thread 1228
MSI (s) (BC:6C) [10:05:25:593]: Leaked MSIHANDLE (318) of type 790541
for thread 1228
MSI (s) (BC:6C) [10:05:25:593]: Note: 1: 2769 2: ConfigureSql 3: 5
DEBUG: Error 2769: Custom Action ConfigureSql did not close 5
MSIHANDLEs.
Internal Error 2769. ConfigureSql, 5
Action ended 10:05:25: ConfigureSql. Return value 3.
I am using WIX 2.0.4415.0
What can I tell you about it:
1. In my case its occuring during a major upgrade during the installation
of the new version.
2. It is not a hard problem. On our main test server (where we needed to
get the install completed so the testers could work) it was occuring 95% of
the time. On a second test server about 50% of the time and on a
development PC (with IDE etc) only ever once.
3. I cannot get a consistent pattern to bringing the problem on. Some
times a reboot will clear the problem, other times it occurs straight after
a reboot.
4. On the 2nd test server it was more likely to occur if the MSI was
accessed from a UNC path rather than local. But again this was not
consistent.
5. I tried to debug the custom action (I was using the Remote debug tools
in VS2003 to attach to the test server). But when I used a DLL that allowed
debugging the error would not occur. Its almost as if the problem is to do
with timing (the test servers are both Virtual Machines).
However. It does appear to be happening in the inital part of the Custom
Action, before it begins scripting the deferred custom actions. Next is
the relevant snippet of the log if the error does not occur:
MSI (s) (4C:18) [08:50:43:250]: Doing action: ConfigureSql
Action 8:50:43: ConfigureSql. Configuring SQL Server
Action start 8:50:43: ConfigureSql.
MSI (s) (4C:CC) [08:50:43:311]: Invoking remote custom action. DLL:
C:\WINDOWS\Installer\MSI102.tmp, Entrypoint: ConfigureSql
MSI (s) (4C!08) [08:50:56:163]: PROPERTY CHANGE: Adding CreateDatabase
property. Its value is 'DBSQL2?PERM-WIN2K3??CINS?1?1???0?0'.
MSI (s) (4C!08) [08:50:56:183]: Doing action: CreateDatabase
Action 8:50:56: CreateDatabase. Creating Databases
Action start 8:50:56: CreateDatabase.
1: Creating Databases
Action ended 8:50:56: CreateDatabase. Return value 1.
MSI (s) (4C!08) [08:50:56:244]: PROPERTY CHANGE: Adding
ExecuteSqlStrings property. Its value is
'sqlserver_Master?PERM-WIN2K3??master?-2147483648? 1???SingleUser_RI?17?alter
database CINS set SINGLE_USER With Rollback Immediate?backup_RI?17?backup
database CINS to disk='C:\DOCUME~1\ADMINI~1.TES\LOCALS~1\Temp\CINS.bak' with
INIT'.
MSI (s) (4C!08) [08:50:56:254]: Doing action: ExecuteSqlStrings
Action 8:50:56: ExecuteSqlStrings. Executing SQL Strings
Action start 8:50:56: ExecuteSqlStrings.
1: Executing SQL Strings
Action ended 8:50:56: ExecuteSqlStrings. Return value 1.
MSI (s) (4C!08) [08:50:56:305]: PROPERTY CHANGE: Adding
RollbackExecuteSqlStrings property. Its value is
'sqlserver_Master?PERM-WIN2K3??master?-
2147483648?1???restore_singleUser_RI?25?alter database CINS set SINGLE_USER
With Rollback Immediate?restore_drop_RI?25?drop database
CINS?restore_cmd_RI?25?restore database CINS from
disk='C:\DOCUME~1\ADMINI~1.TES\LOCALS~1\Temp\CINS.bak'?multiUserRB_RI?25?alter
database CINS set MULTI_USER'.
MSI (s) (4C!08) [08:50:56:326]: Doing action: RollbackExecuteSqlStrings
Action 8:50:56: RollbackExecuteSqlStrings. Rolling back SQL Strings
Action start 8:50:56: RollbackExecuteSqlStrings.
1: Rolling back SQL Strings
Action ended 8:50:56: RollbackExecuteSqlStrings. Return value 1.
I am happy to help further in getting to the bottom of this, but am unsure
what you need further.
Michael
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share
your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
