7.10-beta-7 Released

[kiroscell]

@neil9000 I was using Imagesearch and Youtube Scraper but I removed them. Still crashing.

 

I see some basic information in the Eventvwr 

Application: BigBox.exe
Framework Version: v4.0.30319
Description: The process was terminated due to an unhandled exception.
Exception Info: exception code c0000005, exception address 00007FFBB320FD0C

This happened immediately after uprading to the latest beta so I figured it was an issue with the Beta. I was originally launching games in Bigbox then I went to launch 'desktop view' Launchbox to add some new games. I was prompted to DL the latest Beta which I did... added my games then re-launched Big Box and no go.

 

 

Faulting application name: BigBox.exe, version: 7.10.0.9, time stamp: 0x5924ada0
Faulting module name: d3d9.dll, version: 10.0.15063.0, time stamp: 0x631de416
Exception code: 0xc0000005
Fault offset: 0x000000000000fd0c
Faulting process id: 0x290c
Faulting application start time: 0x01d2d4832bbe735b
Faulting application path: D:\LaunchBox\BigBox.exe
Faulting module path: C:\WINDOWS\SYSTEM32\d3d9.dll
Report Id: 805ed5f3-236c-42e8-9205-4a54cb8f6d58
Faulting package full name:
Faulting package-relative application ID:

[DOS76]

I'm not an expert but it might be a dx9.dll based of the faulting module path that could corrupted or missing

 

[neil9000]

3 minutes ago, kiroscell said:

Faulting module path: C:\WINDOWS\SYSTEM32\d3d9.dll

I am not familiar with error codes but, that clearly to me looks like a DirectX issue. Have you tried updating it?

Damn you Dos.  

[kiroscell]

Hmmm... strange. I'll try to replace the DLL with a different copy but I didn't do anything other than update so this is strange.

Edited May 24, 2017 by kiroscell

[cammelspit]

2 hours ago, kiroscell said:

Anyone else getting an immediate crash when launching BigBox or is it just me?

DO you have any plugins installed? Remove them all and reinstall them from a fresh download one at a time. I was able to find exactly which plugin was locking it up on boot, at least for me.

[kiroscell]

Found the problem. I use Rivatuner OSD to send hardware data to the game like Vid Memory and GPU Usage. This never really worked for Big Box so I just disabled this feature for Bigbox specifically. Heads up if anyone's using any type of OSD software like Afterburner.

[neil9000]

Good to know, glad you got it sorted.  

[Nielk1]

2 hours ago, DOS76 said:

Okay @Jason Carr I just noticed this when I combined two games it makes two additional apps including a duplicate one for the facing game is this expected behavior I thought the dropdown would let you choose the game you wanted to be the face game and would only make the additional app for as however many games you were combining with the game that is still showing.

I think this is intended.  If you are merging 2 games, yes, the main one becomes the primary, but it makes sense that in the extended list of options you'd have "Play Version 1.0" and "Play Version 2.0" even if "Play" would start 2.0 anyway, as the 2 additional options are being descriptive but the Play option is just a quick launch sort of option.

[Nielk1]

@Jason Carr I found something useful you might want to put into your app.config (launchbox.config / bigbox.config) that will allow you to not only update the version number on the plugin API DLL in the future safely without breaking old plugins (provided the needed functions, properties, and classes are still there, .net is very permissive) but allow plugins to reference the other DLLs in the rare cases it's needed without needing to be recompiled for every LaunchBox/BigBox version.  (Even though bindings in .net say "any version" for some reason it doesn't work very well, I think that just allows for this binding redirect.)

<configuration>

  <runtime>
    <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
      <dependentAssembly>
        <assemblyIdentity name="LaunchBox" culture="neutral" />
        <bindingRedirect oldVersion="0.0.0.0-7.10.0.9" newVersion="7.10.0.9" />
      </dependentAssembly>
      <dependentAssembly>
        <assemblyIdentity name="BigBox" culture="neutral" />
        <bindingRedirect oldVersion="0.0.0.0-7.10.0.9" newVersion="7.10.0.9" />
      </dependentAssembly>
      <dependentAssembly>
        <assemblyIdentity name="Unbroken" culture="neutral" />
        <bindingRedirect oldVersion="0.0.0.0-7.10.0.9" newVersion="7.10.0.9" />
      </dependentAssembly>
      <dependentAssembly>
        <assemblyIdentity name="Unbroken.LaunchBox" culture="neutral" />
        <bindingRedirect oldVersion="0.0.0.0-7.10.0.9" newVersion="7.10.0.9" />
      </dependentAssembly>
      <dependentAssembly>
        <assemblyIdentity name="Unbroken.LaunchBox.Library" culture="neutral" />
        <bindingRedirect oldVersion="0.0.0.0-7.10.0.9" newVersion="7.10.0.9" />
      </dependentAssembly>
      <dependentAssembly>
        <assemblyIdentity name="Unbroken.LaunchBox.Wpf" culture="neutral" />
        <bindingRedirect oldVersion="0.0.0.0-7.10.0.9" newVersion="7.10.0.9" />
      </dependentAssembly>

      <dependentAssembly>
        <assemblyIdentity name="Unbroken.LaunchBox.Plugins" culture="neutral" />
        <bindingRedirect oldVersion="0.0.0.0-1.0.0.0" newVersion="1.0.0.0" />
      </dependentAssembly>
    </assemblyBinding>
  </runtime>

</configuration>

 

[Jason Carr]

Thanks guys. @Nielk1 I've used that in the past and that will ensure that versions match up and that versioning isn't an issue, but it still won't fix the problem of a broken interface. In fact, in order to avoid having to do all that I don't change the version numbers on the plugin DLL when I put out a new version. The issue is though, you'll get a crash if you try and load up a new version of an interface with added members when a plugin was compiled against an older version.

[Jason Carr]

8 hours ago, Nielk1 said:

I think this is intended.  If you are merging 2 games, yes, the main one becomes the primary, but it makes sense that in the extended list of options you'd have "Play Version 1.0" and "Play Version 2.0" even if "Play" would start 2.0 anyway, as the 2 additional options are being descriptive but the Play option is just a quick launch sort of option.

Yes, that is by design.

[Jason Carr]

19 hours ago, cammelspit said:

Just update to beta 9, still getting immediate exceptions and fully crashing LB/BB about half the time. I posted a bitbucket for it soon as beta8 came out but 9 is behaving identically. No changes from me.

 

UPDATE: Had to clear my plugins folder 100% and LB/BB is working so something was working in beta7 that no longer works. No idea which one yet.

Are you still getting crashes @cammelspit? Can you explain where and when? Is it on startup?

[Jason Carr]

Beta 10 is out now guys. It's mainly only minor additions and fixes, though I did add the translators to the About menu. Also new is a PluginHelper.StateManager.GetAllSelectedGames which will return all selected games at any time whether you're in LaunchBox or Big Box. I'm hoping this will be a good release candidate, though I'm not sure what's going on with @cammelspit above.

[cammelspit]

Turned out to be a plugin that was fixed but the DL link to the fixed version was broken. So no, not at all right now.

[Nielk1]

4 hours ago, Jason Carr said:

Thanks guys. @Nielk1 I've used that in the past and that will ensure that versions match up and that versioning isn't an issue, but it still won't fix the problem of a broken interface. In fact, in order to avoid having to do all that I don't change the version numbers on the plugin DLL when I put out a new version. The issue is though, you'll get a crash if you try and load up a new version of an interface with added members when a plugin was compiled against an older version.

Changes to the interfaces can range from stable to unstable.  .net is interesting.  If it was C we'd have to make sure we only put new externs on the bottom of the existing externs for backwards compatibility, but this is C#.  Under C# if you grab an instance of a type defined in a remote DLL, and that instance comes from that remote DLL, you won't crash unless you try to call a function that doesn't exist.  The only problem will be for the plugin interfaces where the plugins need to implement every function/method.  The fix for that is to make all the current plugin interfaces end in 001 and when you make a change bump the number up and make a new inteface.  Thus, you'd have IGameMenuItemPlugin001, and you'd have IGameMenuItemPlugin002:IGameMenuItemPlugin001, and you'd have IGameMenuItemPlugin003:IGameMenuItemPlugin002 and so on.  By doing that you ensure that future plugins can use the newer interface and older plugins can still use the older one.  You could use a thin-adapater instance to encapsulate the manual polymorphism on on these various interfaces.

The assembly redirects will help with plugins that do more complex operations like SteamTools which loads BigBox.exe as an assembly so it can access the static root view to inject its modal dialog.  Even though you added that to the plugin interface I still need references to non-plugin libraries to be able to cast the games view to TextGamesViewModel so I can call RefreshGames().  I can rebuild my SteamTools for every single release you make if I need to so it doesn't crash on people, but that is a bit rough.  I can also write my code to dynamically rebind to later versions, but other people aren't that knowledgeable.  SteamTools is in beta though and there's a lot of crashes I need to insulate against and things I need to fix anyway that I won't push on you.

 

Also, in reference to what was discussed in the stream, I have a rough prototype working of a thin-server plugin:

Edited May 25, 2017 by Nielk1