04-15-2009 06:57 PM
If I had any hair left, I'd be tearing it out!
My plugin/dll loads and executes flawlessly on at least 15 machines where it's been used, but on one machine, when the dll is in the \Plugins folder for an ACT! 11.1.183 XP machine, ACT! fails IMMEDIATELY with an "ACT! has encountered a problem and must shut down.".
LogViewer show an empty log (after removing the ACTLOG and ACTLOG2 .xml files before starting ACT!.) When my dll is removed, it starts just fine, and produces a DependentDLLs.xml file and Log files, which the LogViewer shows as "clean" with a few Info msgs. Remove those 3 files, put back my dll, restart ACT! and it crashes, with none of those 3 files being rebuilt!
I've put a Msgbox as the first statement in the OnLoad event, but it fails to appear before the error occurs.
And all this weirdness only happens on this one machine!! User has nuked-and-paved machine, to no avail. His \Plugins folder holds the same files as mine, where the dll works fine.
What can cause ACT! to fail during the load process, preventing even the creation of the DependentDLLs file, and producing not ACTLOG files?
Solved! Go to Solution.
04-16-2009 11:23 AM - edited 04-16-2009 11:25 AM
Are all the other machines on 11.1.183 as well? Or are they on 11.0?
Are you using any of the following 'Act.Framework.MutableEntities.MutableEntity.FieldCollection' exceptions?
During the nuke and pave was .NET removed and reinstalled? (Edit: I think yes if this is related to your other thread).
04-16-2009 01:17 PM
No, the other machines are running anything from 10.0.2 on up, including some others on 11.1.183.
There are no specific references to any of the exception types that you list.
As far as I know, yes. I also verified the existence of the C:\Windows\Microsfot.NET\Framework\v1.0.3705, \v1.1.4322, \v2.0.50727, \v3.0 and \v3.5 folders, which, as far as I know, indicates that all those versions of the dotNet Framework are installed.
Do those answers lead you to any ideas or eliminate any suspects?
04-21-2009 11:25 AM
I've reset all the ACT! logging levels to 5 in the ACTSage.exe.config file, and now LogViewer shows a bunch of informational messages as it loads various dll's. The last entry is a similar informational msg that it's loading MY dll, then nothing - no error, no completion, no nothing! Apparently it can't load the dll, but instead of putting it on the blacklist in DependentDLLs.xml and continuing, it just STOPS.
Any ideas, please!
Anybody got an XP sp3 machine running ACT! at the 10.02 level or higher willing to try the install on your machine to see if it behaves the same? I don't have any problem with it on ANY of my machines, so I'm kind of stuck.
Thanks in advance,
04-21-2009 04:44 PM
Since this odd error only occurs on one machine it is safe to assume the error is environmentally caused and you are going to have to debug it on that client. It also sounds like the error occurs after ACT! attempts to load the plugin but before ACT! gets control back from the .NET CLR and the exception is so odd it is being caught by the handler of last resort. If reloading the box is out of the question ( I assume it is), I would recommend the following, although it is not simple. I apologize as the learning curve on this tool may be more than you want to take on if you are not familiar with it or native windows development. If you don't want to go down this rabbit hole, this method won't help but I do understand.
Install WinDbg on the machine, it is part of the debugging tools for windows.(http://www.microsoft.com/whdc/devtools/debugging/d
Once you get it up and working start windbg and tell it to execute actsage.exe. Be sure to set the start directory appropriately . At this point ACT! will start to run and load. You will see lots of DLLs fly by, and you will see lots of first chance exceptions that will break the debugger. ignore these and hit F5 to continue. There are many and they are quite normal in an exception handling style of development, they are not always indicative of application errors so don't panic! Eventually, I expect you will see your DLL get loaded (by the process, not ACT!) and a exception be thrown. Hopefully this exception will directly lead you to your problem.
Please remember that most first chance exception are expected and handled. Try it on your dev box first so you get a feel for what a "normal" load looks like, it will still be strewn with exceptions. Remember you may need to hit F5 many times before ACT! is up to the contact detail (or wherever) and just running idle. Since you have a plug in, once you are up and running on a good box your plugin load already happened. You should be able to search up the list and see where it came into the process and what normally happens around that so you can compare to the bad box.
Sorry for the lack of a simple answer, I'm not a simple guy
04-22-2009 08:35 AM
Thank you VERY much for your reply, as complex as it is :-) I am not surprised that it's not simple - if it was, we would have solved the problem already. I'm going to proceed with your suggestions, and let you know the results, even if it takes a few days to work through the various steps and complexities.
Again, thanks for taking the time to go thru it all.
04-22-2009 09:19 AM
Hopefully someone will chime in and say "Don't use that! Use <simple tool name here>!" You may also have success wiht CorDbg, which is a .NET debugger similar to WinDbg. You can read more about it on msdn, I have personally never used it. It may be an easier choice and filter out some of the lower level stuff.
This link may be of some value to you: http://msdn.microsoft.com/en-us/library/ms954594.a
04-26-2009 04:06 PM
With massive support and encouragement from Stan Smith, we were able to finally track down and eliminate this nasty habit.
Iit was, indeed, a dot net error - at least we fixed it by uninstalling dot net 3.5, 3.0, and 2.0 then reinstalling 2.0 and 3.5 (with SP1 and the Family Update) from Windows Update. It probably could also have been fixed with the 3.5 sp1 Family Update, since that "hot fix" had our problem listed as a problem that the update fixes. However, just applying the update to a machine with 3.5 sp1 didn't solve it, while uninstalling back to 2.0 and rebuilding from there, DID fix it.
Thanks to Logan and Tim for your assistance.
We can close this one :-)
04-27-2009 10:01 AM
Just curious, but did you actualy get to record the error code or exception? Just curious in case this ever comes up again.
Glad you got past it though.