MSI unloading crash - MSI leaves thread running...
Dean Taylor
which
causes an "Access Violation" (crash) when that thread
continues
again...
The access violation is at:
0x7718887d - MSI.DLL -
MsiUiMessageConext::ChildUIThread
If anybody else has had a problem with there application
crashing
randomly after unloading MSI.dll this could be it!
If Microsoft or anybody else has any anwsers, get-rounds,
or questions please respond to the email address at the
bottom...
The best way I could re-create this problem was to
create the following:
- New Win32 Application
- New Win32 Dynamic-Link Library - InstallApp.DLL
Here is some simplified code to reproduce the problem...
//////////// Application - Begin //////////
typedef BOOL (__stdcall *FARINSTALLAPPPROC) ();
int APIENTRY WinMain(xxx)
{
HMODULE hInstallAppDll = LoadLibrary
("InstallApp.DLL");
FARINSTALLAPPPROC fnInstallApp =
(FARINSTALLAPPPROC)GetProcAddress(hRes, "InstallApp");
BOOL bReturn = fnInstallApp();
MessageBox(NULL, _T("Dummy Msg1"), _T("Dummy
Msg1"), MB_OK);
MessageBox(NULL, _T("Dummy Msg2"), _T("Dummy
Msg2"), MB_OK);
MessageBox(NULL, _T("Dummy Msg3"), _T("Dummy
Msg3"), MB_OK);
FreeLibrary(hInstallAppDll);
return 0;
}
//////////// Application - End //////////
//////////// CheckInstallPackage.DLL -
Begin ///////////////
BOOL __stdcall InstallApp(void)
{
HMODULE hMsiDll = LoadLibrary("MSI.DLL");
// ...do GetProcAddress for funcs
required... and put into msiFuncs struct
// NOTE: this next function call starts a
UI thread, the one
// that will crash because the thread is
not closed before the
// dll is unloaded.
msiFuncs.MsiOpenPackage("c:\\x_prod.msi",
&msiHandle);
msiFuncs.MsiCloseHandle(msiHandle);
FreeLibrary(hMsiDll);
return TRUE;
}
//////////// CheckInstallPackage.DLL - End ///////////////
Thanks and kind regards...
--------------
Dean Taylor
mailto: mog...@myrealbox.com
Phil Wilson
msi*.h, linking to msi.lib and calling the documented APIs, not doing load/freelibrary,
GetProcAddress etc). It seems a bit unusual to me.
"Dean Taylor" <mog...@myrealbox.com> wrote in message
news:112a001c21a11$402c5a90$9be62ecf@tkmsftngxa03...
Dean Taylor
the all of the operating systems my products support e.g.
Win95.
If MSI.DLL (and the approperate functions) are unavaiable
the standard (VSI) SETUP.EXE stub will be executed.
Otherwise version information will be checked and the
product will only be installed if newer than the one
installed.
Thanks for your responce...
Dean.
>.
>
Phil Wilson
msi.dll like this. It looks to me as if msi.dll isn't expecting to be unloaded from its hosting
process at some arbritrary point.
1) Why not install the Windows Installer engine on Windows 95?
2) Even if the installer engine is installed, are you checking that the version is adequate for what
you want to do?
3) You're basically doing your own "late-binding" depending on whether the installer engine is on
the system or not. You should be using the automation interface which is specifically designed for
late binding clients.
My apologies for preaching.
"Dean Taylor" <mog...@myrealbox.com> wrote in message
news:11b2201c21bbb$63d0d560$b1e62ecf@tkmsftngxa04...
Rich [Microsoft Windows Installer MVP]
"Phil Wilson" <ju...@nowhere.com> spake the secret code
<af87b8$158h$1...@si05.rsvl.unisys.com> thusly:
>In general, I'd say you're skating on thin ice here, I don't think we're
>supposed to get into msi.dll like this.
I disagree. Using GetProcAddress on a DLL supplied export is
perfectly fine and there's nothing wrong with doing that. When you
staticly link to msi.lib, you're just getting the program loader to
attach/detach msi.dll to your process at startup/shutdown time.
>It looks to me as if msi.dll isn't expecting to be
>unloaded from its hosting
>process at some arbritrary point.
To me it just looks like a resource leak in msi.dll.
--
Ask me about my upcoming book on Direct3D from Addison-Wesley!
Direct3D Book <http://www.xmission.com/~legalize/book/>
izfree: Open source tools for Windows Installer
<http://izfree.sourceforge.net>
Andreas Magnusson
know if msi is installed or not. A lot more easy than setting up all those
proc addresses. (Especially if you suddenly need to support more calls)
/Andreas
Andre Stille
"Dean Taylor" <mog...@myrealbox.com> schrieb im Newsbeitrag news:11b2201c21bbb$63d0d560$b1e62ecf@tkmsftngxa04...
> It is done this way because MSI.DLL may not be avaiable on
> the all of the operating systems my products support e.g.
> Win95.
Use delay-load for the msi.dll. Saves lots of trouble.
HTH
Andre Stille
Dean Taylor
> I don't think we're supposed to get into msi.dll like
this.
file!
> 1) Why not install the Windows Installer engine on
Windows 95?
--- Waste of time if its already installed, considering
this process may happen may times over, as the product is
ran may times in a single session.
> 2) Even if the installer engine is installed, are you
checking that the version is adequate for what you want to
do?
--- For the functions i'm using, if they exist they are
the right versions!
> 3) You're basically doing your own "late-binding" ...
You should be using the automation interface ...
--- It would be a waste of resources to load a dll, and
add extra un-required code to manage automation.
---
Delay-loading msi.dll still leaves the thread running.
---
As a quick get-round, the application that is loading the
custom dll is also loading msi.dll (if available) before
loading/calling the custom dll. The application then
leaves it as late as possible to unload msi.dll. Since the
application displays a dialog, msi.dll is unloaded late
enough for the strange msi UI thread to close.
Thanks for all you input...
This is still a problem with MSI.DLL as far as I can see...
does anybody know whom/where I can report this possible
bug to?
Thanks again,
Dean.
>.
>
Phil Wilson
picture:
1) Installing the Windows Installer engine is pretty straightforward, just run the appropriate
package (or let your tool package it with your msi file) and let Microsoft decide whether to update
the engine. Dean describes this as a "waste of time", so he's re-inventing the wheel and building
his own.
2) There are two well documented and understood ways to get into the installer API. Use
early-binding to msi.lib, include the header files and you're there. Or use the automation
interfaces - do CreateObject or equivalent and invoke the automation calls. Dean has decided that
neither of these will do, and guess what, it doesn't work. Surprise surprise. Dean calls the extra
coding to use automation as "extra unrequired code" (which is how I would describe most of his
approach).
There is such a thing as KISS, and it's usually a good design approach. When it's not applied to
installation design, the result can be as nasty as you've seen. And people wonder why installations
break so much and are difficult to get right?
"Rich [Microsoft Windows Installer MVP]" <legaliz...@mail.xmission.com> wrote in message
news:af880s$9sp$1...@terabinaries.xmission.com...
Rich [Microsoft Windows Installer MVP]
"Phil Wilson" <ju...@nowhere.com> spake the secret code
<uwqK5PiHCHA.2640@tkmsftngp11> thusly:
>Well I didn't explicitly say that GetProcAddress was the wrong thing to
>do, but look at the overall picture: [...]
I agree that the problem can be avoided entirely by going with the
established ways of instalilng the MSI engine. However, I would still
say its a bug if resources are leaked when C-style CPI functions are
called via LoadLibrary.