|
Finalizers always run on the single dedicated finalizer thread,
so they will never ever run on the correct thread to call MsiCloseHandle. This
problem is likely not occurring frequently because there’s probably not
enough garbage generated by light.exe to actually cause GC to occur and the
finalizable objects to end up on the finalization queue. My best practice is to always call Dispose() on anything that
implements IDisposable, and anything which offers a Dispose() method (which
should implement IDisposable, but sometimes I find that this has been omitted,
which is annoying because you can’t then use a using() block). I’m not quite sure why the decision was taken to make
Database, Record, SummaryInformation and View inherit MsiHandle rather than to
own one – an is-a rather than a has-a relationship. Another best practice
is to keep classes that manage unmanaged resources as small as possible, and be
responsible only for managing that resource; acting as a base class would seem
incompatible with that. -- Mike Dimmick From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Rob
Mensching Yeah, that’s a good point. We try to wrap all the
handles in a “using” call but I expect there are some Record
handles that are not disposed of directly. I wonder if we should work
through the code and make sure everything is disposed of explicitly. 1. Just look on the release share and you’ll see the
latest build. It’s something like 4604. 2. Okay. 3. If this only happened once then I’m not going to
stress about it too much. However, I would greatly appreciate if you
could open a bug to track this issue and if more people hit we can up the
priority of hunting for the fix. 4. If you hit this again, I’d be very much interested
to hear about it... add a comment to the bug to make sure we can track to see
how often this hits. From: Ilya Kleyman Rob, MSDN documentation for MsiCloseHandle at
http://windowssdk.msdn.microsoft.com/en-us/library/aa370067.aspx says that the
function must be called from the same thread that requested creation of the
handle. Given that the below call-stack is that of a finalizer called into by
.NET GC, it is not clear how this requirement can be satisfied by managed code,
which does not know what thread GC will use to call. Just a random shot. Ilya From: Ilya Kleyman
Don’t know whether it is relevant or not, but examining the
part of the build log that is immediately preceding the crash, I see that
build-thread 102 was calling into candle.exe (in the previous e-mail I had dots
in the place where this was happening). Here is the updated part of the log: 102>Stop. . . . 102>
tools\wixcop.exe -nologo -f -indent:4 CCCCCC.wxs 102>
tools\candle.exe -nologo -wx -IDIR1 -IDIR2 -DVAR1=”VAL1" -dVAR2="VAL2"
-dMSI_COMPRESSION_LEVEL=high -out DDDD.wixobj –dVAR3=”VAL3"
CCCCCC.wxs 101>Laying out
media. 101>Moving file
‘. . . \b4fepmve\YYYY.msi' to ‘. . . YYYY.msi’. 101>Copying file
‘. . . \DIR1\ABCDEF.sys' to ‘. . .\DIR2\ABCDEF.sys'. . . . 101> 101>Unhandled
Exception: System.AccessViolationException: Attempted to read or write
protected memory. This is often an indication that other memory is corrupt. 101> at
Microsoft.Tools.WindowsInstallerXml.Msi.Interop.MsiInterop.MsiCloseHandle(IntPtr
database) 101> at
Microsoft.Tools.WindowsInstallerXml.Msi.MsiHandle.Close() 101> at
Microsoft.Tools.WindowsInstallerXml.Msi.MsiHandle.Dispose(Boolean disposing) 101> at
Microsoft.Tools.WindowsInstallerXml.Msi.MsiHandle.Finalize() 102> CCCCCC.wxs 102>
tools\candle.exe -nologo -wx -IDIR1 -IDIR2 -dVAR1="VAL1"
-dVAR2="VAL2" -dMSI_COMPRESSION_LEVEL=high -out EEEE.wixobj
FFFFFF.wxs 102>
FFFFF.wxs 101>NMAKE : fatal
error U1077: ‘. . \tools\light.exe' : return code '0xc0000005' 101>Stop. Ilya From: Rob Mensching You could try moving to a more recent build. There were
some minor fixes but nothing that I think will actually fix this.
I’m a bit at a loss on how to even go about debugging this. What
version of the CLR are you running? I wonder if maybe there is a double
Dispose() in the code somehow. Does this happen often? Is there a way to get a debugger
on it? We could pull the exception handler off of light.exe to see if we
can’t get it to fault into the default debugger on the machine if it
repros often. From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Ilya
Kleyman Wix-Users, We
are seeing the following access violation in light.exe (filever 2.0.4409.0)
that seems to have something to do with concurrent invocation of two instances
of light.exe. Has anyone seen something similar? Unhandled Exception:
System.AccessViolationException: Attempted to read or write protected memory.
This is often an indication that other memory is corrupt. at
Microsoft.Tools.WindowsInstallerXml.Msi.Interop.MsiInterop.MsiCloseHandle(IntPtr
database) at
Microsoft.Tools.WindowsInstallerXml.Msi.MsiHandle.Close() at
Microsoft.Tools.WindowsInstallerXml.Msi.MsiHandle.Dispose(Boolean disposing) at
Microsoft.Tools.WindowsInstallerXml.Msi.MsiHandle.Finalize() Two
build threads simultaneously laying out two different MSIs were working at the
time of failure (prefix at the beginning of each line is build-thread index) Excerpts
from the build-log showing the immediate pre-history of the problem is below. “Stop.”
message indicates that the build thread has finished its work. I am omitting
non-essential information for clarity. 101>
tools\light.exe -nologo -wx -v0 -out XXXX.msi Xa.wixobj Xb.wixobj Xc.wixobj
Z1.wixobj Z2.wixobj sca.wixlib wixca.wixlib 102>
tools\light.exe -nologo -wx -v0 -out YYYY.msi Ya.wixobj Yb.wixobj Yc.wixobj
Z1.wixobj Z2.wixobj sca.wixlib wixca.wixlib 102>Updating file information. 101>Updating file
information. 102>Generating
database. 102>Merging
modules. 101>Generating
database. 101>Merging
modules. 102>Processing
media information. 102>Cabbing file
X0001.aaa . . . . <68
files> 101>Processing
media information. 101>Cabbing file
Y0001.bbb . . . . <149
files> 102>Importing
streams. 102>Importing
binary stream from X0001.ccc . . . . <12
streams, icons, cabs> 101>Importing
streams. 101>Importing
binary stream from Y0001.ddd . . . . <15
streams, icons, cabs> 102>Laying out
media. 102>Moving file
‘. . . .\txxd3s8j\XXXX.msi' to ‘ . . . XXXXX.msi'. . . . 102>Stop. . . . . 101>Laying out
media. 101>Moving file
‘. . . \b4fepmve\YYYY.msi' to ‘. . . YYYY.msi’. 101>Copying file
‘. . . \DIR1\ABCDEF.sys' to ‘. . .\DIR2\ABCDEF.sys'. . . . 101> 101>Unhandled
Exception: System.AccessViolationException: Attempted to read or write
protected memory. This is often an indication that other memory is corrupt. 101> at
Microsoft.Tools.WindowsInstallerXml.Msi.Interop.MsiInterop.MsiCloseHandle(IntPtr
database) 101> at
Microsoft.Tools.WindowsInstallerXml.Msi.MsiHandle.Close() 101> at
Microsoft.Tools.WindowsInstallerXml.Msi.MsiHandle.Dispose(Boolean disposing) 101> at
Microsoft.Tools.WindowsInstallerXml.Msi.MsiHandle.Finalize() . . . 101>NMAKE : fatal
error U1077: ‘. . \tools\light.exe' : return code '0xc0000005' 101>Stop. Thanks, Ilya |
------------------------------------------------------------------------- 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
