Wow, wickedly awesome! This is fantastic... thank you so much. I've had
nightmares about this bug.
More likely than not memory got corrupted somewhere before that call and
StrAllocStringAnsi() just happened to touch it the second time thus blowing up.
At least, that was my conjecture before, your analysis will hopefully help us
nail this bug. Thanks so much.
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Michael Osmond
Sent: Tuesday, December 05, 2006 03:01
To: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] ConfigureSQL Bug
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]<mailto:[EMAIL PROTECTED]>] On Behalf Of Dana Gutride
Sent: Wednesday, November 29, 2006 05:40
To: wix-users@lists.sourceforge.net<mailto: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]<mailto:[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 <mailto: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
