Could this blow up the machine

[fla]

There have been two reports of xrecord causing severe stability problems to gbpvr systems (here and here). The only bizarre thing I have noticed in xrecord's design is that the fastfindplugin.dll is installed in two places. It is itself a plugin so it must live in the Plugins directory. It also provides services to the XGuide and XRecord plugins and those plugins won't start unless fastfindplugin.dll is in the gbpvr directory.

I noticed that the recording service seems to load the copy of fastfindplugin.dll in the gbpvr directory!?!?!? (can't delete it without stopping the recording service).

Other than refactoring fastfindplugin.dll into a fastfindutilities.dll + fastfindplugin.dll, how can the copy of fastfindplugin.dll in the gbpvr directory be avoided? How can the XRecord + XGuide plugins find the code in Plugins\fastfindplugin.dll instead?

[sub]

There have been two reports of xrecord causing severe stability problems to gbpvr systems (here and here).

Its hard to tell, but I'd be inclined to think xrecord wouldnt cause either of those. I didnt read the whole threads, just the posts linked.

The first one, with the memory gobbled up, you'd probably need to run something like perfmon and log the private bytes used by GBPVR.exe and GBPVRRecordingService.exe.log to get a real view of what amount of memory is being used, and which of the two processes is using it, and if its just jumping up significant - under what circumstances, or over what time period. Sometimes people jump to conclusions without looking into the facts... then roll back to previous versions not giving you a chance to analyse.

The other one, hanging the machine, sounds more like a driver or machine instability type thing. There isnt really user mode type stuff a .net app can do to cause this sort of problem. This sort of issue would usually occur in protected mode stuff like drivers.

[zehd]

How can the XRecord + XGuide plugins find the code in Plugins\fastfindplugin.dll instead?

They have to be programmed to look for the files in that location. Unless you re-engineer the code, you won't be able to move the location of those files...

Why do you want to change the intended directories for those files...?

[fla]

Why do you want to change the intended directories for those files...?

I don't want to move any files, just delete the duplicate copy of fastfindplugin.dll that sits in devnz\gbpvr.

Why would the recording service keep gbpvr/fastfindplugin.dll open? It doesn't open xrecord's RecordingUtils.dll in the same directory.

Sub you are loading the dll's from the Plugins directory, could I load the Plugins\fastfindplugin.dll from xrecord and xguide if it hasn't already been loaded ?

[sub]

Sub you are loading the dll's from the Plugins directory, could I load the Plugins\fastfindplugin.dll from xrecord and xguide if it hasn't already been loaded ?

I dont think .net will look in the plugins directory by default to resolve external dependencies. It would normally expect these to be in the same directory as the running application (gbpvr.exe). You might be able to do it by creating a GBPVR.exe.config (and config.exe.config etc), which has something like:

Code:

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
   <runtime>
      <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
         <probing privatePath="plugins"/>
      </assemblyBinding>
   </runtime>
</configuration>

[fla]

Thanks, I'll try to play with this. Even if it doesn't fix any system crashes, if I can get rid of the duplicate gbpvr\fastfindplugin.dll at least the xrecord installer won't have to stop/restart the recording service anymore. Can be a pain when working on fastfind restarting the recording service to drop in the dll.

[sub]

That said, I dont know if you really want to create a gbpvr.exe.config though, since I've seen other plugins do it aswell, which could lead to trampling on each others stuff.

[fla]

That said, I dont know if you really want to create a gbpvr.exe.config though, since I've seen other plugins do it aswell, which could lead to trampling on each others stuff.

Sub I tried your example config file and it works but I agree it's preferable for plugins not to mess with gbpvr's config file.

Would it make sense for gbpvr to use AppDomainSetup.PrivateBinPath to add something like Plugins/SharedDLL to the private bin path? Instead of dumping their utility dll's into gbpvr's root, plugin installers would dump them into there.

This would make it clear which dll's belong to gbpvr and which belong to plugins.

If you added something like this to gbpvr, I'd modify XRecord's installer right away to use it.