cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
MartinaIFER
Level 4

Two self-registering dlls and InstallScript Setup Launcher problem

Hi,

We have two self-registering dlls in our Install script project. When running the installation on XP, we end up with "InstallScript Setup Launcher has encountered a problem and needs to close. ..." If we include just one (any) of the two dlls into the project, the installation is fine. If we manually register both dlls, again, everyting is fine. We do not have any idea what the problem can be.

Thank you very much,

Martina
Labels (1)
0 Kudos
(6) Replies
DemonPiggies
Level 7

So if you include both and let InstallShield register them, you get the error, right?

Check your options to see how InstallShield is registering them. Under the Preferences tab there is a section called 'Self-Registration.' You may need to try playing with those settings to see which one works for you. I had a similar issue with my project where non-.Net dlls were erroring out when InstallShield installed them. Originally we had to manually register these files in the script but after finding an explanation online about the 'Self-Registration' tab we pieced it together.

Hope that helps abit...
0 Kudos
MartinaIFER
Level 4

Thank you very much for your help.

Both the dlls should be self-registered. The second dll is actually a new version of first one, we keep both of them in the installation becouse of compatibility reasons for our application.

Thanks again!
0 Kudos
joshstechnij
Level 10 Flexeran
Level 10 Flexeran

Does this behavior occur if you include these DLLs and mark them as self registering in a test InstallScript project? If so, can you send the test project and the DLLs so that we can investigate further?
0 Kudos
MartinaIFER
Level 4

This is excelent! Attached you can find the the project, the dlls are in the dll subfolder.

The error appears only on XP, everything is fine on Vista or Windows 7 . If I try to use the regsvr32, again no error appears.

Thank you very much for your offer.

Martina
0 Kudos
joshstechnij
Level 10 Flexeran
Level 10 Flexeran

This does not appear to be a crash with the InstallScript engine, nor one that it can prevent. This crash appears to be occurring in gdiplus.dll on XP machines (and probably doesn't on other platforms due to changes in gdiplus). Some investigation revealed the following:
- The crash always seems to occur after unloading CustomSymbol_library2.dll, and the crash address is always 0x4ec957ed (note this may be different based on the build of gdiplus.dll on a machine and the base address gdiplus.dll is loaded at).
- The address 0x4ec957ed maps to a function named BackgroundThreadProc in gdiplus.dll based on debugger output:

0:004> g
ModLoad: 02df0000 02ef3000 C:\Program Files\IFER\FM_Test\CustomSymbol_library2.dll
ModLoad: 4ec50000 4edf3000 C:\WINDOWS\WinSxS\x86_Microsoft.Windows.GdiPlus_6595b64144ccf1df_1.0.2600.2180_x-ww_522f9f82\gdiplus.dll
ModLoad: 5edd0000 5ede7000 C:\WINDOWS\system32\olepro32.dll


gdiplus!BackgroundThreadProc:

.text:4EC957ED ; unsigned long __stdcall BackgroundThreadProc(void *)
.text:4EC957ED ?BackgroundThreadProc@@YGKPAX@Z proc near
.text:4EC957ED ; DATA XREF: BackgroundThreadStartup(void)+38
.text:4EC957ED mov edi, edi


Based on our testing, this crash did not always occur. With this behavior in mind, and the name of the gdiplus function that crashes, this issue implies that timing is involved because of multithreading. It would seem that gdiplus isn't shut down correctly based on the fact that one of its thread procedures is being called after gdiplus.dll has been unloaded (that is the only reason the instruction at the start of BackgroundThreadProc can crash, since it does not touch any memory).

Further investigation showed that GdiplusShutdown is never called by CustomSymbol_library2.dll, indicating that gdiplus will never be properly shut down. In addition, it appears that CustomSymbol_library2.dll calls GdiplusStartup from its initialization routine (DllMain), which the docs for GdiplusStartup indicate should never be done. This appears to be the case based on the call stack that results from the InstallScript engine calling LoadLibrary to load CustomSymbol_library2.dll before calling any of its entry points:

0:000> k
ChildEBP RetAddr
0013b690 02eb6a31 gdiplus!GdiplusStartup
WARNING: Stack unwind information not available. Following frames may be wrong.
0013b6c0 02df4acc CustomSymbol_library2!DllUnregisterServer+0xa8e79
0013b710 7c9011a7 CustomSymbol_library2+0x4acc
0013b730 7c91cbab ntdll!LdrpCallInitRoutine+0x14
0013b838 7c916178 ntdll!LdrpRunInitializeRoutines+0x344
0013bae4 7c9162da ntdll!LdrpLoadDll+0x3e5
0013bd8c 7c801bb9 ntdll!LdrLoadDll+0x230
0013bdf4 100f88b1 kernel32!LoadLibraryExW+0x18e
0013bef8 100f87dd ISSetup!CFileRegistrar::DllRegistration+0x51


The InstallScript engine does have try/catch handlers wrapping DLL registration code. However, try/catch handling is done per-thread, and since this exception is occurring on a thread the engine does not own, it has no possible way of preventing or catching this behavior.

This DLL (CustomSymbol_library2.dll) should likely be changed to correctly initialize and shut down GDI+ to resolve this behavior. Using regsvr32.exe to register the EXE is only masking the crash that occurs when registering with the InstallScript engine.
0 Kudos
MartinaIFER
Level 4

Dear Josh,

Thank you very much! This is like a "working" Christmas present, I appreciate it very much.

Martina
0 Kudos