Rob,
Some more information. I have spent some time adding log messages into both
ConfigureSQL and ScaSqlStrsReadScripts (in scasqlstr.cpp).
We have been able to narrow down that the crash occurs in the function
"StrAllocStringAnsi" but not where or why. In this case it appears to be
while processing the first script file in the install sequence.
It appears as though we don't get a return from StrAllocStringAnsi.
We hope to spend a little more time on it tomorrow.
Michael
-----Original Message-----
From: Michael Osmond
Sent: Thu 30/11/2006 8:27 AM
To: wix-users@lists.sourceforge.net
Cc:
Subject: RE: [WiX-users] ConfigureSQL Bug
Dana, Rob,
Thanks for the info.
A few stats from me. We have been using WIX to ship 10 production
systems (these are server based installs) for almost 2 years. Most have been
built on Wix 2.3220 as it was stable and working at the time we started. Until
recently I did all of our upgrades as minor upgrades - and never saw this issue
other than on the mailing list. So I concur this happens only in a Major
upgrade scenario.
At first I thought it was something to do with the contents of the SQL
scripts. Because I now have 2 systems using the major upgrade and one does
exhibit this problem and the other doesn't. From an MSI point of view there
is nothing different between the two installer packages - they use the same
file names and install sequence, its just the contents of the SQL scripts that
are different.
But (there's always a but) ... looking at a log where it fails and a
log that is good (see the bottom of my first email) it appears that the script
crashes at the start before it starts reading the script tables.
I was just starting to put some log messages into the code yesterday
afternoon a la Rob's suggestion. So I will spend some more time on that today.
I need to nail this one if we can. Please bear with me though I am not a
developer by trade so things like pageheap don't mean a great deal.
Michael
_____
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dana
Gutride
Sent: Thursday, 30 November 2006 2:58 AM
To: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] ConfigureSQL Bug
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] <mailto:[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]
<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
