not sure what happened, but after the last update, the app takes two…

[twidget76]

not sure what happened, but after the last update, the app takes two double clicks to open, when it does open, it's not seeing my log and log on so nothing really works. Not sure what's going on.

---

EQBuddy 1.84.0 · Windows 26200

[DranakCorps-bot]

Thanks for reporting this quickly — a problem that starts right after an update is exactly what I want to hear about fast, and v1.84.0 went out only a couple of hours before you posted.

I want to be straight with you: I can't tell you the cause yet, and I'd rather ask you four specific questions than ship a guess at a fix. Two separate things are happening in your description (a launch that needs two attempts, and the log not being read), and they may or may not share a cause.

The reassuring part first. Whatever else is going on, v1.84.0 is the release that stopped EQBuddy throwing log data away — archiving is now on by default. If your log looks empty, check Logs\archive inside your EverQuest Legends folder: finished sessions are kept there as eqlog_yourname_server_YYYYMMDDHHMMSS.txt. EQBuddy never deletes anything in there.

What would tell me the most:

1. error.log. Press ⊞Win+R and paste %APPDATA%\EQBuddy — there should be an error.log. If there's anything in it from today, paste it here. This is the single most useful thing.
2. Task Manager → Details: how many EQBuddy.exe are listed? EQBuddy only allows one copy at a time; a second launch asks the first to show itself and then exits. If a stale copy is still running from the update, that would explain a first double-click appearing to do nothing and the second working — and it would mean the copy you're looking at may not be the one that's actually reading.
3. ⚙ Options → is the log folder still correct? And does the status dot next to the character name go green while the game is running and writing?
4. What version does the title bar show once it does open — 1.84.0, or something older?

Two things worth trying in the meantime, both harmless:

• Fully exit EQBuddy (right-click the tray icon → Exit, and confirm no EQBuddy.exe remains in Task Manager), then start it once.
• If Options shows the wrong log folder, re-pick it there — it's the fastest fix if that's all it is.

If it turns out v1.84.0 broke something, I'd rather know within the day and put out a fix release than have people work around it. So please do follow up either way, including if it starts behaving on its own — "it fixed itself after a reboot" is still information about what it was.

[twidget76]

1. Attached
2. I uninstalled and installed the 1.83.0 version and everything is working again.
3. Yes, the folder was still listed correctly
4. It just hangs now. It would show up in task manager but no cpu utilization and wasn't even registering on the taskbar as it being opened.
   error.log

[DranakCorps-bot]

Found it. This is my bug, it's in 1.84.0, and you were right to roll back. Thank you for the error.log — it had the whole answer in one stack frame:

System.NullReferenceException
   at EQBuddy.MainWindow.OnEpicClassicOnlyToggled(...)
   at ToggleButton.set_IsChecked(...)
   at EQBuddy.MainWindow..ctor()          <-- inside the constructor

What happened. EQBuddy restores your saved settings onto its controls as it builds the window. Ticking that checkbox raises its "changed" handler — and in 1.84.0 I reorganised the quest checklists into a separate component, which that handler now calls into. But it gets built thirty lines later. So the constructor threw before the window existed.

That's your symptom exactly: a process in Task Manager using no CPU, never reaching the taskbar, never opening a window. And the second double-click did nothing because the first launch had left a process behind — EQBuddy allows only one copy, so the second politely asked the first to show itself, and the first was in no state to.

The trigger is the Epic card's "classic-doable only" filter. If you have it ticked, 1.84.0 cannot start. If you don't, it's fine — which is why this isn't affecting everyone, and why I couldn't guess at it from the first description.

Nothing was damaged. It failed before touching anything: your settings, session history and logs were never written to during those launches. Your rollback to 1.83.0 was exactly the right move.

Why my own tests missed it, since I'd rather say than not: there's an automated test that launches the real app and checks the Epic checklist renders — but it ran with that filter off. Assigning "off" to an already-unticked box raises no event at all, so the entire bug lived in a path the test never entered. That test now runs with the filter on, and I checked it fails against the old code before keeping it — a regression test that doesn't catch the regression is just decoration.

The fix is in and the next release carries it. Until then 1.83.0 is the right place to be, or untick the classic-only filter before updating.

Genuinely: thank you for the rollback detail and the log. "It works on 1.83.0" plus that stack trace turned this from a mystery into a ten-minute fix, and you saved everyone else with that filter ticked from hitting it.

[n3cr0nk1tt3n]

I want to add on to this. I did the same update for 1.84.0 and am having the same issue. I will have to reinstall EQBuddy with the latest pull with the patch pushed. Since the app launches straight into the widget, there's no way for a casual user to rollback to a previous stable version. I know we are in beta and pushing many patches per day, but perhaps we can design a bootstrap that lets the user select what version to launch the widget into (defaulted with the latest) with the previous stable version as an alternative as way to mediate downtime for users and still allow them to open the widget and pull the next stable update without reinstalling.

[DranakCorps-bot]

Thanks for confirming it — a second report with the same rollback is what turns "one machine" into "a real bug", and you'd already given me the version that works.

The fix is out: v1.85.0, published a few minutes ago. The cause was exactly as described above — restoring the Epic card's "classic-doable only" checkbox at startup called into a part of the app that hadn't been built yet, so the constructor threw and no window ever appeared. If you had that filter ticked, 1.84.0 could not start. Nothing of yours was damaged; it failed before touching settings, history or logs.

Since you're currently stuck on a build that won't open: you can install 1.85.0 straight over it — grab EQBuddySetup.exe from the release page and run it. There's no need to uninstall first, and no need to get 1.84.0 running to update from inside the app.

---

On the bootstrap idea — this is a good point and I want to take it seriously rather than nod at it.

You've identified something real: EQBuddy's updater lives inside the widget, so a build that won't open takes the update path down with it. That's a single point of failure I'd never had cause to notice, and "reinstall from GitHub" is a fine answer for you and a poor one for a casual player who doesn't know the release page exists.

Two things I'd want to think through before building a version picker, and I'd value your read on them:

1. A launcher is another thing that can break, and it sits in front of everything. If it fails, nothing opens at all — so it would need to be far simpler and far more stable than the app it guards.
2. Keeping the previous version around means the installer stops replacing files and starts managing a set of them, which is a real change to how EQBuddy installs.

There may be a smaller version of your idea that gets most of the value: the installer already keeps the previous build's uninstaller, so a "Roll back to the previous version" shortcut in the Start menu — no launcher, no version list, no change to how the app starts — would cover exactly the case you hit. Less flexible than choosing from a list, but nothing new stands between you and the app on a normal day.

I'm flagging both to David rather than committing to either. Would the rollback shortcut have solved your morning, or does the picker earn its complexity for a reason I'm missing?

And genuinely — thank you for reporting it while stuck rather than just rolling back and moving on.

[DranakCorps-bot]

Built, and I went with the smaller of the two options — with your reasoning attached, so you can tell me if it misses the point.

The installer now keeps the build it replaces, and adds a Start-menu entry: "EQBuddy (previous version)". If an update ever leaves you with a widget that won't open, you start that one instead — and a working widget contains a working updater, so you can pull the fix from inside it without going near GitHub.

I chose it over the version picker for one reason: a launcher sits in front of every single launch, and becomes a new thing that can fail. Your whole report was about a single point of failure taking the app down; adding another one in front of it felt like the wrong trade, even though the picker is more flexible. This adds nothing to the normal path — the shortcut just sits there unused until the day it isn't.

Details: it only appears once there is a previous build to go back to, uninstalling removes the kept copy, and if the copy fails for any reason the install carries on regardless — not having a rollback shortcut is a much smaller problem than not having an install.

One thing worth knowing if you ever use it: running an older build against your current settings can drop settings that only the newer version understands. That's true of any rollback, including the manual reinstall you did — it's not a new hazard, just one worth naming.

If the picker still earns its complexity for a case I've missed, say so; the shortcut doesn't preclude it.