unhandled registry exception (Ecco)

[redllar]

Okay, I got the app launching problem solved as well. Please pass along my thanks to whoever it was who told you it was possibly a WinExec return code issue, because it was.

Also, I forgot to mention that I had to edit the .reg you sent me to get the Tools list to display. Are you manually editing the .reg? If you are, the tool you're using is adding additional string terminating bytes onto the end of each hex(1) entry. I suspect maybe it's JPERegger that's doing that.

Also, we need to discuss how to set up the ECCO JPE runtime so that the launched apps make use of the same settings, which is what I assume you want.

First, you need to change the name of the ecco32_jauntepe.ini to JauntePE_jauntePE.ini. Otherwise the launched apps will wind up using different JPE runtime settings. Which means their reg and file system mods will go into different directories and different files and their reg, file system, and module exclusion, inclusion, and ignore lists will be different. So it's best when running multiple apps to use the generic JPE runtime ini naming so that all run apps work from the same "playbook," if you will.

Second, you need to change the line Data=.\Registry\%appname%.reg to Data=.\Registry\ecco32.reg . Otherwise the launched apps wind up creating their own app-specific .reg file.

Third, it's best to put a copy of the JPE runtime into the ECCO home directory and make sure that the ecco32_portable is built "making use of" this set of dlls. That will ensure that all launched apps will find and use the same JauntePE_jauntePE.ini that the ecco32 app made use of. Normally you don't have to do this but with an app that launches other apps it's easier to manage and easier to know where to go to make any future JPE runtime related changes.

That's all I have for now. I think I'm done with this app for now but I'll need to do some more testing using the new JPE dll with other apps to make sure I haven't introduced any new bugs for them.

[sgp]

Just a heads-up, I got the problem solved with the Tools menu not showing the tools entries that were in the .reg.

That's great news.

There something else interesting that you may want to try.
I thought instead of jpeizing ecco why not jpeizing eccoext, and see if it loads better? When eccoext starts and doesn't find ecco it runs it. So I created eccoext_jauntepe.ini and eccoext_portable.exe and ran it.
What's surprising to me is that the ecco that eccoext starts (you have to click on the ecco icon in the systray to see it) loads madhook.dll but not jauntepe.dll. What gives?

This is the ini file

Code: Select all

[Redirection]
Logging=1
FlashDisco=1
IconDisco=1
ModFrame=1
RedirMisc=1

[Registry] 
Use=1 
Data=.\Registry\%appname%.reg 

[Filesystem] 
Use=1 
Data=.\FileSystem 

[FilesystemExclude]
;1=*

[FilesystemInclude]
; 36=windows folder, files created by ecco32
1=%36%\win.ini
2=%36%\ecco.cfx
3=%36%\ecco.fdb
4=%36%\ecco.alm
; files created by eccoext.exe
5=%36%\ecco_cfx.bak
; and also ecco.cfx ecco_cfx.bak ecco.alm ecco.ini ecco_save.ini and a temp
; file, all in the ecco program folder

[ModuleExclude]
;1=*

[ModuleInclude]
;1=ecco32.exe
;2=eccoext.exe

[RegistryExclude]
1=*

[RegistryInclude]
1=HKEY_CURRENT_USER\Software\NetManage\Ecco
2=HKEY_LOCAL_MACHINE\Software\NetManage\Ecco
3=HKEY_CLASSES_ROOT\.eco
4=HKEY_CLASSES_ROOT\.ect
5=HKEY_CLASSES_ROOT\.ecc
6=HKEY_CLASSES_ROOT\.mtg
7=HKEY_CLASSES_ROOT\Applications\ECCO32.EXE
8=HKEY_CLASSES_ROOT\NetManage EccoPro
9=HKEY_CLASSES_ROOT\NetManage EccoPro Mtg Mail
10=HKEY_LOCAL_MACHINE\SOFTWARE\Classes\.ecc 
11=HKEY_LOCAL_MACHINE\SOFTWARE\Classes\.eco 
12=HKEY_LOCAL_MACHINE\SOFTWARE\Classes\.ect 
13=HKEY_LOCAL_MACHINE\SOFTWARE\Classes\.mtg

[RegistryIgnore]
1=HKEY_CURRENT_USER\Software\NetManage\Ecco
2=HKEY_LOCAL_MACHINE\Software\NetManage\Ecco
3=HKEY_CLASSES_ROOT\.eco
4=HKEY_CLASSES_ROOT\.ect
5=HKEY_CLASSES_ROOT\.ecc
6=HKEY_CLASSES_ROOT\.mtg
7=HKEY_CLASSES_ROOT\Applications\ECCO32.EXE
8=HKEY_CLASSES_ROOT\NetManage EccoPro
9=HKEY_CLASSES_ROOT\NetManage EccoPro Mtg Mail
10=HKEY_LOCAL_MACHINE\SOFTWARE\Classes\.ecc 
11=HKEY_LOCAL_MACHINE\SOFTWARE\Classes\.eco 
12=HKEY_LOCAL_MACHINE\SOFTWARE\Classes\.ect 
13=HKEY_LOCAL_MACHINE\SOFTWARE\Classes\.mtg

[redllar]

When I started logging what was going on, I discovered that the jpe dll does get injected into the ecco32 process. It's just "going away" for some unknown reason. I've seen that happen before when I had incorrectly specified a hook - madCHook would just unload the hooking dll.

What I also noticed though, by looking at the dependencies of the eccoext process, is that it too is making use of the same set of api functions that are used for dll injection. So there's probably some sort of interaction going on there that I hadn't considered before.

I'm sure there's a solution. I actually got it to work once, so it's just a timing thing. I just need to figure out how to make it consistent.

[sgp]

I'm sure there's a solution. I actually got it to work once, so it's just a timing thing. I just need to figure out how to make it consistent.

I hadn't realized before that hooking could fail due to timing issues. Come to think of it, I could almost swear that sometimes I see jpeized apps without their window red border - which means the jauntepe.dll isn't loaded. Is this a general problem we could encounter jpeizing apps? Could you make it more robust, do you think?

[redllar]

Come to think of it, I could almost swear that sometimes I see jpeized apps without their window red border - which means the jauntepe.dll isn't loaded.

Not necessarily. There might be some apps that draw their windows themselves. JPE can't draw onto those windows.

Is this a general problem we could encounter jpeizing apps? Could you make it more robust, do you think?

No, this isn't a general problem. It's specific to apps that launch other apps and then inject their own dlls into those other app's processes. That's what eccoext is doing.

I did some testing and I can get things synched up as they should be, but unfortunately, since eccoext is using the same dll injection technique that madCHook uses (or one similar in technique) problems are caused that wind up crashing ecco. The good news is that all of what eccoext does now gets redirected.

The best I can do is to have an ini entry where you can specify enough info for JPE to resolve the issue to continue the app. It's a hack and not very user-friendly but it'd work in this case since we already know what the problem is.

So for now, you just can't use eccoext with a JPEized ecco. Unless you can get the dev to re-write it using a SetWindowsHookEx call to get his dll injected, instead of modifying ecco's startup code to do a LoadLibrary call.

[sgp]

The best I can do is to have an ini entry where you can specify enough info for JPE to resolve the issue to continue the app. It's a hack and not very user-friendly but it'd work in this case since we already know what the problem is.

I'd like to try this hack.

So for now, you just can't use eccoext with a JPEized ecco. Unless you can get the dev to re-write it using a SetWindowsHookEx call to get his dll injected, instead of modifying ecco's startup code to do a LoadLibrary call.

Let me try the hack first to see what else I can learn. After that I will talk to the dev, too.

[redllar]

I'd like to try this hack.

Well, it won't happen anytime soon as I consider this a low priority feature request. It's not something that I can just throw in and expect it to work.

[sgp]

OK, I misunderstood you. I can wait, thank you.

[redllar]

OK, I misunderstood you. I can wait, thank you.

Great. I think what needs to be done here is perfect for an 020 plugin.

Anyway, I will have the synching issue resolved in the next release, so at least if you launch ecco via eccoext, ecco's registry changes will get redirected into the .reg. But due to eccoext's overlaying of the madCHook code to inject the JPE runtime, ecco will then crash. That's the more complicated part to code up so that what's going on can be identified at runtime and then auto-corrected. So I'm going to put that off for later.

[sgp]

Cool! version 0.1.6 works with ecco and ecco extension, thanks!
I have to use a fixed launch sequence, first ecco_portable.exe then eccoext.exe -l (that's lowercase L). I have added the latter as an ecco toolbar launch item.
Starting eccoext_portable.exe directly doesn't get ecco.exe started. But at least now there's a way to get ecco and its extension to work together portably!