Hi, i try to start dolphin (yesterday work with no issue) and closes inmediately i open it, try to open again and closes again.
My windows is optimized so doesnt actualizate automatically, try with older versions and the same happened.

While running DBT with first=6997 and last=9511, I got an exception:

See the end of this message for details on invoking 
just-in-time (JIT) debugging instead of this dialog box.

************** Exception Text **************
SevenZip.SevenZipArchiveException: Invalid archive: open/read error! Is it encrypted and a wrong password was provided?
If your archive is an exotic one, it is possible that SevenZipSharp has no signature for its format and thus decided it is TAR by mistake.
   at SevenZip.SevenZipBase.ThrowException(CallbackBase handler, Exception[] e)
   at SevenZip.SevenZipExtractor.OpenArchive(IInStream archiveStream, ArchiveOpenCallback openCallback)
   at SevenZip.SevenZipExtractor.GetArchiveInfo(Boolean disposeStream)
   at SevenZip.SevenZipExtractor.ExtractArchive(String directory)
   at DolphinBisectTool.Backend.Download(String url, String major_version, Int32 version)
   at DolphinBisectTool.Backend.Bisect(String boot_title)
   at DolphinBisectTool.MainWindow.start_button_Click(Object sender, EventArgs e)
   at System.Windows.Forms.Control.OnClick(EventArgs e)
   at System.Windows.Forms.Button.OnClick(EventArgs e)
   at System.Windows.Forms.Button.OnMouseUp(MouseEventArgs mevent)
   at System.Windows.Forms.Control.WmMouseUp(Message& m, MouseButtons button, Int32 clicks)
   at System.Windows.Forms.Control.WndProc(Message& m)
   at System.Windows.Forms.ButtonBase.WndProc(Message& m)
   at System.Windows.Forms.Button.WndProc(Message& m)
   at System.Windows.Forms.Control.ControlNativeWindow.OnMessage(Message& m)
   at System.Windows.Forms.Control.ControlNativeWindow.WndProc(Message& m)
   at System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam)


************** Loaded Assemblies **************
mscorlib
    Assembly Version: 4.0.0.0
    Win32 Version: 4.6.1076.0 built by: NETFXREL3STAGE
    CodeBase: file:///C:/Windows/Microsoft.NET/Framework/v4.0.30319/mscorlib.dll
----------------------------------------
DolphinBisectTool
    Assembly Version: 1.0.0.0
    Win32 Version: 1.0.0.0
    CodeBase: file:///D:/Programs/Games/Platforms/Gamecube/Dolphin.Bisect.Tool/DolphinBisectTool.exe
----------------------------------------
System.Windows.Forms
    Assembly Version: 4.0.0.0
    Win32 Version: 4.6.1055.0 built by: NETFXREL2
    CodeBase: file:///C:/Windows/Microsoft.Net/assembly/GAC_MSIL/System.Windows.Forms/v4.0_4.0.0.0__b77a5c561934e089/System.Windows.Forms.dll
----------------------------------------
System
    Assembly Version: 4.0.0.0
    Win32 Version: 4.6.1075.0 built by: NETFXREL3STAGE
    CodeBase: file:///C:/Windows/Microsoft.Net/assembly/GAC_MSIL/System/v4.0_4.0.0.0__b77a5c561934e089/System.dll
----------------------------------------
System.Drawing
    Assembly Version: 4.0.0.0
    Win32 Version: 4.6.1068.2 built by: NETFXREL3STAGE
    CodeBase: file:///C:/Windows/Microsoft.Net/assembly/GAC_MSIL/System.Drawing/v4.0_4.0.0.0__b03f5f7f11d50a3a/System.Drawing.dll
----------------------------------------
System.Configuration
    Assembly Version: 4.0.0.0
    Win32 Version: 4.6.1055.0 built by: NETFXREL2
    CodeBase: file:///C:/Windows/Microsoft.Net/assembly/GAC_MSIL/System.Configuration/v4.0_4.0.0.0__b03f5f7f11d50a3a/System.Configuration.dll
----------------------------------------
System.Core
    Assembly Version: 4.0.0.0
    Win32 Version: 4.6.1055.0 built by: NETFXREL2
    CodeBase: file:///C:/Windows/Microsoft.Net/assembly/GAC_MSIL/System.Core/v4.0_4.0.0.0__b77a5c561934e089/System.Core.dll
----------------------------------------
System.Xml
    Assembly Version: 4.0.0.0
    Win32 Version: 4.6.1067.0 built by: NETFXREL3STAGE
    CodeBase: file:///C:/Windows/Microsoft.Net/assembly/GAC_MSIL/System.Xml/v4.0_4.0.0.0__b77a5c561934e089/System.Xml.dll
----------------------------------------
Accessibility
    Assembly Version: 4.0.0.0
    Win32 Version: 4.6.1055.0 built by: NETFXREL2
    CodeBase: file:///C:/Windows/Microsoft.Net/assembly/GAC_MSIL/Accessibility/v4.0_4.0.0.0__b03f5f7f11d50a3a/Accessibility.dll
----------------------------------------
SevenZipSharp
    Assembly Version: 0.64.3890.29348
    Win32 Version: 0.64.3890.29348
    CodeBase: file:///D:/Programs/Games/Platforms/Gamecube/Dolphin.Bisect.Tool/SevenZipSharp.DLL
----------------------------------------

************** JIT Debugging **************
To enable just-in-time (JIT) debugging, the .config file for this
application or computer (machine.config) must have the
jitDebugging value set in the system.windows.forms section.
The application must also be compiled with debugging
enabled.

For example:

<configuration>
    <system.windows.forms jitDebugging="true" />
</configuration>

When JIT debugging is enabled, any unhandled exception
will be sent to the JIT debugger registered on the computer
rather than be handled by this dialog box.

If the bisect fails for whatever reason, the user can just pick up where they left off.

Delroth changed infra so that pulling index.html isn't possible anymore. A reasonable change, but this breaks DBT.

The solution is to implement support in the dolphin website to allow DBT to pull a list of builds. I have a PR for that that I need to finish. Putting this here for documentation

DBT is currently worded to find "culprit" PRs, where a problem is introduced. Sometimes it is necessary to find "Solution" PRs that solve a problem too.

Perhaps a new menu could be added?
The PR in question:

• Introduces a problem
• Solves a problem

If "Solves a problem" is selected, swap the "Select a development build that is broken" and "Select a development build that worked" labels. "GOOD" and "BAD" would need to be swapped in the log. And the message that identifies the "culprit" PR when finished should probably be changed to "solution."

or find a way to make VS move it to External Libs

I was investigating https://bugs.dolphin-emu.org/issues/10563 and verified https://dolphin-emu.org/download/dev/master/5.0-76/ is the culprit PR. DBT correctly identified 5.0-76 as the culprit in its notice message. The log however displays an incorrect PR.

no idea whats causing this.

They're more modern (And effectively standard nowadays) game file formats offered by Dolphin that are pending support for bisecting purposes.

the default WinForms icon sucks

When testing is interrupted for any reason, it can be hard to determine which versions have been successfully tested and what the progress of the bisect is. A simple text log file showing build numbers and the user's selected result would make it easier to continue testing in the event the bisect is unexpectedly terminated early.

While bisecting it's possible to come across an unstable or otherwise a build that does not allow the bug to be tested. After closing the program, the bisect tool asks "Yes" or "no" whether the bug occurred. If the bug wasn't able to be tested this throws off the progression of the bisect. An "Unsure" option that simply ignored the results of that particular test and went on to another build would help.

On some builds, the Dolphin filename is DolphinWX.exe, not Dolphin.exe. For example builds 298, 299, 300.

If DBT tries to start such a build, an exception is thrown as it cannot find Dolphin.exe.

See the end of this message for details on invoking 
just-in-time (JIT) debugging instead of this dialog box.

************** Exception Text **************
System.ComponentModel.Win32Exception (0x80004005): The system cannot find the file specified
   at System.Diagnostics.Process.StartWithShellExecuteEx(ProcessStartInfo startInfo)
   at System.Diagnostics.Process.Start()
   at DolphinBisectTool.RunBuild.Run(String title)
   at DolphinBisectTool.Backend.Bisect(String boot_title)
   at DolphinBisectTool.MainWindow.start_button_Click(Object sender, EventArgs e)
   at System.Windows.Forms.Control.OnClick(EventArgs e)
   at System.Windows.Forms.Button.OnClick(EventArgs e)
   at System.Windows.Forms.Button.OnMouseUp(MouseEventArgs mevent)
   at System.Windows.Forms.Control.WmMouseUp(Message& m, MouseButtons button, Int32 clicks)
   at System.Windows.Forms.Control.WndProc(Message& m)
   at System.Windows.Forms.ButtonBase.WndProc(Message& m)
   at System.Windows.Forms.Button.WndProc(Message& m)
   at System.Windows.Forms.Control.ControlNativeWindow.OnMessage(Message& m)
   at System.Windows.Forms.Control.ControlNativeWindow.WndProc(Message& m)
   at System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam)


************** Loaded Assemblies **************
mscorlib
    Assembly Version: 4.0.0.0
    Win32 Version: 4.6.1076.0 built by: NETFXREL3STAGE
    CodeBase: file:///C:/Windows/Microsoft.NET/Framework/v4.0.30319/mscorlib.dll
----------------------------------------
DolphinBisectTool
    Assembly Version: 1.0.0.0
    Win32 Version: 1.0.0.0
    CodeBase: file:///D:/Programs/Games/Platforms/Gamecube/DolphinBisectTool105/DolphinBisectTool.exe
----------------------------------------
System.Windows.Forms
    Assembly Version: 4.0.0.0
    Win32 Version: 4.6.1055.0 built by: NETFXREL2
    CodeBase: file:///C:/Windows/Microsoft.Net/assembly/GAC_MSIL/System.Windows.Forms/v4.0_4.0.0.0__b77a5c561934e089/System.Windows.Forms.dll
----------------------------------------
System
    Assembly Version: 4.0.0.0
    Win32 Version: 4.6.1075.0 built by: NETFXREL3STAGE
    CodeBase: file:///C:/Windows/Microsoft.Net/assembly/GAC_MSIL/System/v4.0_4.0.0.0__b77a5c561934e089/System.dll
----------------------------------------
System.Drawing
    Assembly Version: 4.0.0.0
    Win32 Version: 4.6.1068.2 built by: NETFXREL3STAGE
    CodeBase: file:///C:/Windows/Microsoft.Net/assembly/GAC_MSIL/System.Drawing/v4.0_4.0.0.0__b03f5f7f11d50a3a/System.Drawing.dll
----------------------------------------
System.Configuration
    Assembly Version: 4.0.0.0
    Win32 Version: 4.6.1055.0 built by: NETFXREL2
    CodeBase: file:///C:/Windows/Microsoft.Net/assembly/GAC_MSIL/System.Configuration/v4.0_4.0.0.0__b03f5f7f11d50a3a/System.Configuration.dll
----------------------------------------
System.Core
    Assembly Version: 4.0.0.0
    Win32 Version: 4.6.1055.0 built by: NETFXREL2
    CodeBase: file:///C:/Windows/Microsoft.Net/assembly/GAC_MSIL/System.Core/v4.0_4.0.0.0__b77a5c561934e089/System.Core.dll
----------------------------------------
System.Xml
    Assembly Version: 4.0.0.0
    Win32 Version: 4.6.1067.0 built by: NETFXREL3STAGE
    CodeBase: file:///C:/Windows/Microsoft.Net/assembly/GAC_MSIL/System.Xml/v4.0_4.0.0.0__b77a5c561934e089/System.Xml.dll
----------------------------------------
Accessibility
    Assembly Version: 4.0.0.0
    Win32 Version: 4.6.1055.0 built by: NETFXREL2
    CodeBase: file:///C:/Windows/Microsoft.Net/assembly/GAC_MSIL/Accessibility/v4.0_4.0.0.0__b03f5f7f11d50a3a/Accessibility.dll
----------------------------------------
SevenZipSharp
    Assembly Version: 0.64.3890.29348
    Win32 Version: 0.64.3890.29348
    CodeBase: file:///D:/Programs/Games/Platforms/Gamecube/DolphinBisectTool105/SevenZipSharp.DLL
----------------------------------------

************** JIT Debugging **************
To enable just-in-time (JIT) debugging, the .config file for this
application or computer (machine.config) must have the
jitDebugging value set in the system.windows.forms section.
The application must also be compiled with debugging
enabled.

For example:

<configuration>
    <system.windows.forms jitDebugging="true" />
</configuration>

When JIT debugging is enabled, any unhandled exception
will be sent to the JIT debugger registered on the computer
rather than be handled by this dialog box.

For the first run Boot Title option will work. Afterwards, it produces error: "The specified file "/b" does not exist" when selecting to Start. Then Dolphin resorts to loading the usual title list. If its relevant this in the build range of 5.0-2000 to 5.0-4000. It's possible the /b option is just broken in those builds but I don't think so.

Build 4.0-722 is a bit strange.

Build numbers situation

Build 4.0-722 was originally generated as a result of a commit with parent 4.0-720, with two file changes. Subsequently, build 4.0-732 was generated as a result of a commit with parent 4.0-722, with ten file changes.

However, some time later (between builds 4.0-746 and 4.0-748), a commit was made with parent 4.0-720 with one file change. This build was therefore numbered 4.0-721, even though it came after 4.0-746. After that, another commit with one file change was made with parent 4.0-720. This build was also numbered 4.0-721 and the original 4.0-721 plus its commit ceased to exist outside of Dolphin's own database.

Now, another commit was made with a parent of (the new) 4.0-721. So this build was numbered 4.0-722 by the build tool. This overwrote the original 4.0-722, so that build is no longer available on the build server. However, the 4.0-722 commit was simply a revert of the parent 4.0-721 commit, so that this new 4.0-722 build is identical to 4.0-720. Furthermore, the two commits leading to the new 4.0-721 and the new 4.0-722 were subsequently nuked from the repository, even though they are still accessible on GitHub's database.

Since there are two builds called 4.0-721 and 4.0-722 on Dolphin's database, the Dolphin website (accessed by DBT via "dolp.in") cannot handle the situation and displays an "Internal Server Error" when trying to load the detail pages for these builds.

Build numbers summary

Numbering the first and second versions of 4.0-721/722 with "a" and "b" suffixes for clarity, the parent structure looks like this:

4.0-720 -> 4.0-722a -> 4.0-732 -> ... -> 4.0-746 -> 4.0-748 -> ... -> 5.0-xxx
        \
         \-> 4.0-721a
          \
           \-> 4.0-721b -> 4.0-722b

(NB: 4.0-721a, 4.0-721b and 4.0-722b are not ancestors of the current Dolphin versions.)

Whereas the chronological series looks like this:

4.0-720 -> 4.0-722a -> 4.0-732 -> ... -> 4.0-746 -> 4.0-721a -> 4.0-721b -> 4.0-722b -> 4.0-748 -> ... -> 5.0-xxx

The details of the builds' availability;

4.0-720, 4.0-732, 4.0-746, 4.0-748 (normal builds):

• Build IS available on the build server
• Build details CAN be viewed through "dolp.in"
• Commit IS available in GitHub
• Commit IS available in the Git repository

4.0-721a:

• Build IS NOT available on the build server (was overwritten by 4.0-721b)
• Build details CANNOT be viewed through "dolp.in" (with or without the "a" suffix)
• Commit IS NOT available in GitHub
• Commit IS NOT available in the Git repository

4.0-721b:

• Build IS available on the build server
• Build details CANNOT be viewed through "dolp.in" (with or without the "b" suffix)
• Commit IS available in GitHub
• Commit IS NOT available in the Git repository

4.0-722a:

• Build IS NOT available on the build server (was overwritten by 4.0-722b)
• Build details CANNOT be viewed through "dolp.in" (with or without the "a" suffix)
• Commit IS available in GitHub
• Commit IS available in the Git repository

4.0-722b:

• Build IS available on the build server (but is identical to 4.0-720 in all but number)
• Build details CANNOT be viewed through "dolp.in" (with or without the "b" suffix)
• Commit IS available in GitHub
• Commit IS NOT available in the Git repository (but is identical to 4.0-720 in all but history)

DBT problems

Due to the above anomalies, DBT exhibits some problems. In particular, I had an issue with Dolphin itself which was actually caused by the first Dolphin 4.0-722 (called "4.0-722a" above). DBT reported to me that the issue occurred between 4.0-722 and 4.0-732. This was confusing as the changes between 4.0-722 (the first one) and 4.0-732 were all Android changes, and I was running on Windows. The second 4.0-722 was not in the ancestry chain of 4.0-732 so it seemed DBT could not be referring to the latter build as this would not make sense. Furthermore, DBT provided me with a choice to open the details page of 4.0-722, but as mentioned above, this causes an internal server error.

Of course, what actually happened is that the build which DBT calls "4.0-722" is actually the second 4.0-722, which is identical to 4.0-720 in all but number. This is also not in the ancestry chain of 4.0-732, so it doesn't make sense to say "between 4.0-720 and 4.0-732" (or similar). Instead, the best DBT can say in this situation is that the issue occurred between 4.0-720 and 4.0-732.

Possible solutions

Since the second 4.0-722 and both 4.0-721 builds are not in the commit ancestry chains of current Dolphin releases, it does not really make sense to include these in the bisection at all. However, if a user does get an issue (with Dolphin itself) which occurred between 4.0-720 and 4.0-732, this needs special handling. Normally, DBT assumes it has found a pair of consecutive builds which the issue occurred between, which means it's perfectly acceptable to suggest the user views the build details page for the lower numbered build. However 4.0-720 and 4.0-732 are not consecutive - it's just that the build in-between (the first 4.0-722) is no longer available on the build server and so cannot be tested. For example, DBT could display a message like:

"Your issue seemed to occur between non-consecutive builds 4.0-720 and 4.0-732. Do you want to open the build details page for 4.0-720 or the intermediate build 4.0-722?"

with two options. Of course, if the user elected to open the details page for 4,0-722, we would have to reference the build by the actual commit hash as opposed to the build number, as trying to reference by the build number triggers an internal server error as mentioned above, as the Dolphin website doesn't know which of the two 4.0-722 builds you want to load the details of.

Alternatively, we could even do a manual build of the first 4.0-722 based on the actual commit (still available in the Git repository) and make that available somewhere for DBT to pull instead of the 4.0-722 on the build server (which is basically 4.0-720 for all intents and purposes)?

Recently I have found several bugs in Dolphin's debugger. https://bugs.dolphin-emu.org/issues/10594 is an example.

If DBT could start builds with -d, that'd make bisecting a lot easier.

The logic of the dropdowns are reversed. Top drop down asks for oldest version and bottom asks for newest version, but the program gives an error and expects them the other way.

Unfortunately this makes the program not work at all. I put in "Select a build before the issue occurred" -- 5.0-2690; "Select a build where you saw the issue" -- 5.0-3610. Get: "Error - Second build cannot be less than or equal to the first."

Okay, so i reverse them. Program accepts the numbers. But then it keeps testing in the range where the bug is already confirmed. (E.g., program tests 5.0-3000. Bug occurs? Yes. Then program tests 5.0-3300. It should be testing between 2690 and 3000 at that step.) It just keeps pulling confirmed buggy builds like 3400, 3500, etc..

You can't determine a build download link from its version alone anymore:

For example, the format is no longer :
https://dl.dolphin-emu.org/builds/dolphin-master-[version]-[build]-[arch].7z

But is instead :
https://dl.dolphin-emu.org/builds/[two random hex digits]/[two random hex digits]/dolphin-master-[version]-[build]-[arch].7z

Every build that DBT downloads is marked "4.0.2" in the title bar and Help->About displays the commit hash as ...c3d4f and compiled on Nov 29 2013. Is this expected behaviour?? I feel worried that every single build downloaded by DBT is actually the stable 4.0.2, even though DBT "thinks" they are development builds.

It spits out an error when extracting the archive and I cannot continue bisecting. This can happen if the Windows build failed and doesn't exist (5.0-2409 is one such case), so this would need to be properly handled by falling back to another build.

So the downloaded builds don't interfere with the user data.