This website uses cookies. By clicking Accept, you consent to the use of cookies. Click Here to learn more about how we use cookies.
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
- Revenera Community
- :
- InstallShield
- :
- InstallShield Forum
- :
- Re: Two self-registering dlls and InstallScript Setup Launcher problem
Subscribe
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Subscribe
- Mute
- Printer Friendly Page
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Dec 09, 2010
05:06 AM
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
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
(6) Replies
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Dec 15, 2010
01:20 PM
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...
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...
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Dec 16, 2010
05:28 AM
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!
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!
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Dec 20, 2010
12:57 PM
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?
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Dec 21, 2010
05:05 PM
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:
gdiplus!BackgroundThreadProc:
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:
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.
- 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.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Dec 22, 2010
07:07 AM
Dear Josh,
Thank you very much! This is like a "working" Christmas present, I appreciate it very much.
Martina
Thank you very much! This is like a "working" Christmas present, I appreciate it very much.
Martina
![](/skins/images/D60DF682EA37BF37032955CE10F3F0BB/responsive_peak/images/icon_anonymous_message.png)