GarrisonBuddy does not start

Ok, as Tony suggested, I'm creating a new separate thread for this. The GarrisonBuddy does not start at all. Log: View attachment 7248 2016-08-02 07.37.txt

Other people have exactly same problem:

- https://www.thebuddyforum.com/honor...ot-garrisonbuddy-official-garrison-bot-6.html (pagest 5, 6)
- https://www.thebuddyforum.com/honor...upport/250616-garrisonbuddy-doesnt-start.html

 

No words.

Talk about a very odd way to triage bugs.

 

It is still not working

 

Please understand you are using a TEST RELEASE which has bugs and there are no releases on a daily basis.
Simply give it a couple of more days for the next release and check the release thread if your issue is fixed.
If you want to be 100% on the safe side wait for a final release. NO ETA ;-)

 

That isn't my issue at all, apologies on my part if I failed to communicate this. My reaction was two-fold, firstly triage bugs via a message forum is just bad idea period. It's fragmented at best, it implies ad-hoc "rules" and/or discourages users from participating actively (given the nature of what we are all doing). Lastly and the most important point I'd like to make, based on the original authors log, I know far too much than I should about the configuration of his character alongside timestamps. There's enough information being posted here to leave markers that can isolate the user for a ban. Asking users to submit logs no matter how anonymous they first appear is a bad idea not just from a customer security standpoint but also provides visibility into the various configuration(s) being used.

Less information / digital footprints we provide Blizzard the more healthier we all become in our endeavour to enjoy a good ol fashion "bot" experience.

Individual "thread" creation for bug submissions of the exact same nature is really in the end, lazy given there's a vast amount of open / private software out there that you could leverage to communicate with customers on these specific issues while enabling privacy concerns to remain passive.

So no, it wasn't about ETA at all.

 

Back on topic

System.Exception: Only part of a ReadProcessMemory or WriteProcessMemory request was completed, at addr: 657078B1, Size: 44
at GreyMagic.ExternalProcessMemory.ReadByteBuffer(IntPtr addr, Void* buffer, Int32 count)
at GreyMagic.MemoryBase.Read[T](IntPtr addr)
at Styx.WoWInternals.Garrison.GarrisonInfo.get_Followers()
at GarrisonBuddy.GarrisonBuddy.Start()
at Styx.CommonBot.TreeRoot.‬*​​‎**‎*‫***‎*‏‫‫‪*()

Is now thrown, so you've resolved the "type" from previous exception but have in turn created a new error. Seems a closure issue is occuring. This occurs at the usage of GarrisonBuddy with NO additional plugins/profiles etc loaded (after-market additions stripped back).

 

No, i'm good, solve it or don't but its to your own detriment long-term (quality bands / customer service etc).

See previous explanation of why i won't comply with that directive. Appreciate the response none the less.

 

You really think blizzard would use a log from a forum to ban someone?
Must be a hard life being that paranoid.
1. I dont believe you can 100% identify someone through logs 2. Even if you can a company with standards like Blizzard would never ban because of it. Why? Because a log is easily faked, so if you want somebody to be banned just fake a log and watch him burn

 

1) I know the user in question is likely from EU and is likely using EU realm.
2) I know what time(s) the user was in game and what specific class / race the user was using.
3) I know the user has two specific trinkets of rare qualities as part of their configuration.
4) I know the user was using a Windows 10 Build of a specific number, one that hasn't been updated since July -> Nov.
5) I know the user logged in at Horde Garrison which is Level 3.
6) I know the specific combination and configuration the user is using in spell cast / sequences.

pseduo code time.

var players = SQRSApi.FindPlayersLoggedIn(playerTimestamp).Where(p=> p.class == Deathknight && p=> p.race = troll && p => p.trinket == playerTrinketA && p => p.trinket == playerTrinketB);
var playerEU = players.Where(p=> p.IpAddress.ResolveRealmLocation() == Realms.EU);
var playerLoginZone = playerEU.where(playerLoginZone == zoneiD);
var playerSpellSequenceFilter = playerLoginZone.HasUsedSpellsInSpecificSequences( insertSpellArray);

Now to ram on home the final pass of player data diagnostics.

var isBot = RunBotValidation( playerSpellSequenceFilter );

Like i've stated, i suspect Blizzard could pick a bot from a normal player based on data signatures of their behaviour and has little or nothing to do with client-side checks itself (outside the standard local file integrity checks).

If you've ever used a tool like SQL Reporting for example, you'd soon realise how mickey mouse it is for an average skilled operator to pick apart table structures of data. Blizzard once a week have downtimes where it takes hours for them to transfer data from service layers to in-house data farms. You think its "magic" they can transfer you from realm A to real B with all your data intact as well as "logs" to boot and not be traceable?

Lastly, Bossland we know is on Blizzards hit list, they are a source of agitation - especially due to Overwatch bot likelihood, so them spidering a vBulletien board looking for .log files would not only be a trivial exercise you could ironically create a bot to do it

No wonder bans occur.