The program _iu14D2N.tmp version 51.52.0.0 stopped interacting with Windows and was closed

[neela...@gmail.com]

Hi 

We have our com un-registration logic being run via this inno's tmp binary. On some machine we see Event 1001 and 1002 being registered in the event viewer. From the inno code it seems we try to re-spawn the uninstall exe if it does not run to completion. WER service also has logic to restart the terminated hung application. Now our un-registration workflow which gets executed is basically "regsvr32 /s/u *" on crystal report dll's and the end result is that one instance of regsvr32 /s /u craxdrt9.dll is in a hung state blocking the overall uninstall. on attaching a debugger and checking further I could see that the hung "regsvr32 /s /u craxdrt9.dll" was in the act of making CoCreateInstance on a GUID which pointed me to crystal's keycode.dll clsid. All this from inside DllMain (which is an issue in an of itself) Keeping that aside for now, I could see that the unreg of keycode had already happened (or more precisely the HKCR com entries for keycode were not present). So at this point it seems that the very first instance of _iu14D2N.tmp ran till the point where it un-registeded keycode.dll but then somehow it hung which triggered a re-spawn of uninstall000.exe via innosetup or WER and the subsequent instance of "regsvr32 /s /u craxdrt9.dll" (launched via _iu14D2N.tmp) hung. I verified on a standalso system that that if we unreg keyncode.dll before craxdrt9.dll then the unreg of craxdrt9.dll would hang. The issue is sporadic in that it surfaces only on few machines. Could you please provide any pointers which could help diagnose this issue ? 

Thanks

[Neelabh Mam]

any inputs on the above issue ?

--
You received this message because you are subscribed to a topic in the Google Groups "innosetup" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/innosetup/yKlBxQynStI/unsubscribe.
To unsubscribe from this group and all its topics, send an email to innosetup+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/innosetup/85e33b79-6f1f-45d5-b373-8e7775863285%40googlegroups.com.

[Eivind Bakkestuen]

What does Crystal's support or docs say about unregistration order? If nothing, then you likely need to figure out the correct order to make regsvr calls by hand.

You received this message because you are subscribed to the Google Groups "innosetup" group.
To unsubscribe from this group and stop receiving emails from it, send an email to innosetup+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/innosetup/CAM%2BE%2Bxqvfrif-A-rc1C8fXzsKY3Q3U%3DAxBTM%3DOEhFTRppq%2Bp1g%40mail.gmail.com.

[Neelabh Mam]

I have not come across any crystal kb which highlights the correct reg/unreg order. The order of dll listed in our iss source stanzas is correct (at-least with respect to keycode and craxdrt9 dlls) because it has been working fine for as far back as I remember. We are seeing this on 2019 servers. I also verified that the unreg is in reverse order to the one listed in the iss source sections. 

When the issue was reported to us, The 32 bit regsvr32 /s /u craxdrt9.dll was stuck trying to CoCreateInstance on a GUID which on checking further belonged to crystal's keycode.dll. I also saw that the _iu14D2N  pid mentioned in the 1002 event was not the one currently hang. Being first on the scene I checked the status of keycode.dll's registration in HKCR\CLSID but there were no entries for it in the registry. I immediately moved to a vanilla machine and on a working setup unregistered keycode first and then initiated the unreg of craxdrt9.dll. This hanged just like what happened on the repro machine. Now at this point I have 2 observations:

Given a list of dlls to be registered and unregistered (during install and uninstall respectively) does inno guarantee that the order as specified in the script file would always be preserved. Is there a chance that multiple reg or unreg could be executed in parallel under any circumstance ? This based on procmon logs for few install uninstall runs seems to be okay.

Second, why is the OS detecting that the primary message pump of _iu14D2N.tmp is not responsive ? Does the wait on the child processes (regsvr32) happen on the primary thread ? Has inno's uninstaller registered for a automatic restart or is the OS doing it via some default policy ?

Because the OS is terminating and restarting  _iu14D2N it seems sometimes the very first instance of  _iu14D2N.tmp (after spawning a bunch of unregs) is detected as unresponsive, killed and then restarted. At this point depending upon, till what point the first instance ran or even if it unreg'ed everything successfully (implying the first _iu14D2N  hang is because of a different reason). Any subsequent unconditional _iu14D2N runs are bound to hang because keycode should be registered at the point of craxdrt9 unregistration. But keycode was already unreg'ed via the previous  _iu14D2N instance. So basically at this point I'd like to understand why is the very first instance of  _iu14D2N hanging ? and if there is any way we can disable automatic restart of  _iu14D2N. For now I have disabled wer service to check that. Hopefully with that the first  _iu14D2N which "hangs" will not be terminated allowing us to investigate its state. Though I am not sure if disabling wer is the thing that would disable sutomatic restarts.

To view this discussion on the web visit https://groups.google.com/d/msgid/innosetup/CAH4EOO5r3datj6un3z0LQqnB912ufeR518zU9-kFVXiH_n%3D%3DaQ%40mail.gmail.com.

[Neelabh Mam]

Hi 

Any further inputs on the aspect of _iu14D2n re-spawning the earlier terminated child processes ?