REGULAR SEARCHING IN MEMHACK DOESN"T WORK RIGHT.

[esco]

Wussup Spiro, that bug is back again. Whenever I do a search in memhack it only seems to obey the starting address for the search range, not the ending one. So if I search for 631798 to 631854, it will start at 631798, but might end at 861fe9. Is this a known issue? I've had this happen with older versions of memhack Spiro, and whenever I mentioned it you always fixed it, so I figured I'd let you know.

[WhiteHat]

I've tried this...

MHS version : 4.0.0.13
(I'm not sure which one it is, but as i can remember it was the 2nd one
uploaded. So i can't tell if it's the same version as esco's...)

Game : Warcraft 3 The Frozen Throne ver 1.21a

Search : Data-Type
Data-Type : Byte
Evaluation-Type : Range
From : 0
To : 255
Search Range : 00631798 ~ 00631853

The search result returned value from address 00631798 to 00631FEA.

[L. Spiro]

Actually whenever you mentioned it I never fixed it; it always fixes itself.

It is random per build which makes it impossible to track.


And for those who think it should be a simple thing to search within a desired range, it is. There are no bugs with the range of the search.
But MHS uses a very advanced “3rd search engine” which allows it to store the same number of results in about half the RAM.
This feature is what makes it the fastest searcher, but it uses a compression routine and works heavily with threading.

The range you specificy is the range it scans, always. But somewhere in the compression and decompression something is going wrong causing addresses to be displayed incorrectly.


Take one of those addresses that is out of range and view it in the Hex Editor. It won’t be the value it says it is in the Found Address list (unless it is a Group Search or String Search, in which case the value will be accurate but it will not be what you were wanting to find).



You can avoid corruption of the addresses by increasing your buffer size in the search options.
Corruption only happens when it has to swap in and out from the disk drive, which is yet another streamlined routine which is complicated more by being optimized to load sequentially, yet still supports loading in any order.


L. Spiro

[esco]

You can avoid corruption of the addresses by increasing your buffer size in the search options.
Corruption only happens when it has to swap in and out from the disk drive, which is yet another streamlined routine which is complicated more by being optimized to load sequentially, yet still supports loading in any order.


L. Spiro

Changing the buffer size to even 0x1000 makes no difference. Also if I perform ANY search where the ending address is over 729999, it will return NO RESULTS FOUND. Even when unknown is the search type used. This is impossible of course. I am using the newest version you have available for DL, and I am used to searching thru addresses up to 7b6e40. So this search engine has a HUGE issue somewhere.

[L. Spiro]

I did modify the searches just a little and they are now connected to what may be the problem that is causing other people’s computers to die.

Try this and tell me if you get any message boxes at the start and what the message(s) is/are.
http://www.memoryhacking.com/MemHack/MHS2.rar


L. Spiro

[esco]

I did modify the searches just a little and they are now connected to what may be the problem that is causing other people’s computers to die.

Try this and tell me if you get any message boxes at the start and what the message(s) is/are.
http://www.memoryhacking.com/MemHack/MHS2.rar


L. Spiro

Nope no messages. And the search is still broken.

P.S. I have winxp

[esco]

So Spiro any word on when the search will be fixed?

[L. Spiro]

It can not be fixed unless it breaks when I use it in debug mode, and it never breaks in debug mode.


L. Spiro

[Xanatus]

L. Spiro, you could just add an option to allow only to list addresses that are in the search rang. So when you generate the list, you could just check the address range again to make sure the listed addresses are in the range.
I don't see where the problem is?

[L. Spiro]

As I explained, there is nothing wrong with its ability to search the range you specify. If I ever had such a simple problem I would shoot myself.

As explained, it has to do with the compression and decompression of the addresses.


How about this (Data-Type Search only):
Try an Exact Value for any number except 0 and -1. Check that the range is correct.

Try an Unknown for any range. Check that the range is correct.


If these tests still show results outside of the specified range, I will shoot myself.


L. Spiro

[WhiteHat]

Did this in WarCraft 3 The Frozen Throne v1.21a :

Try an Exact Value for any number except 0 and -1. Check that the range is correct.

Search:
- Data Type : Byte
- Evaluation Type : Exact Value
- Value to Find : 1
- Search Range : 06054938 ~ 06AF8547

Found 90165 results.
Search Result Addresses: 066D5004 ~ 06AF84FC

Try an Unknown for any range. Check that the range is correct.

Search:
- Data Type : Byte
- Evaluation Type : Unknown
- Search Range : 06054938 ~ 06AF8547

Found 3511623 results.
Search Result Addresses: 066D5000 ~ 06AF8546


After i opened Hex Editor for above searches, there is a tiny little green line right above address 066D5000. And the bytes before that address are FFs in red color...

If these tests still show results outside of the specified range, I will shoot myself.

Both test results are within the specified range... Save your bullets for other day...

[L. Spiro]

L. Spiro, you could just add an option to allow only to list addresses that are in the search rang. So when you generate the list, you could just check the address range again to make sure the listed addresses are in the range.
I don't see where the problem is?

Just to be clear about my above reply, there is no filter on the Found Address list because it only searches the range you specify anyway, so if all is working perfectly it will only show addresses in your desired range.

Putting up a filter is only masking the problem.
When using Internal Search Type 2 it uses a compression format to store the addresses and the data they contain.

The number of results it returns is the correct number of results in the range specified, but somewhere in the compression routine the addresses are being corrupted, which finally means that every result it shows in the list should be there (filtering them would be lying), but towards the end of the list the addresses it is showing are more and more incorrect as the address look-up for the compression gets more and more derailed.


Somehow it is able to keep the correct values for the objects though. Only the addresses get screwed.
That is why it looks as though it is a simple range bug.


L. Spiro

[Xanatus]

I understand the problem now, thanks for clearing it up again
Anyway, I have never encountered this problem myself so I can't complain.

[esco]

As I explained, there is nothing wrong with its ability to search the range you specify. If I ever had such a simple problem I would shoot myself.

As explained, it has to do with the compression and decompression of the addresses.

I don't know what it has to do with.... but it is posting addresses OUTSIDE the range of addresses I tell the search to end in. So Something is DEFINITELY wrong. And the way it is, it makes it almost impossible to search for the stuff I need and watch it, without it taking 3 times longer than it should.

How about this (Data-Type Search only):
Try an Exact Value for any number except 0 and -1. Check that the range is correct.

Try an Unknown for any range. Check that the range is correct.


If these tests still show results outside of the specified range, I will shoot myself.

If by range you mean the VALUES it shows, yes they are correct for EXACT or RANGE searches. if I search for an exact number like 1... all I get is results for 1. But unknown searches do NOT work, as I demonstrate below. And the address ranges are totally f-ed for me.

ex:

search for value of 1: range 699900 to 6999999
Displays: 8df000-3fboffe

search for value of unknown: range 700000-7b6e40
Displays: NO RESULTS FOUND (IMPOSSIBLE ANSWER, and I have gotten this for SEVERAL searches that have a start or end address over around 690000!)

search for value of 128: range 650000-690000
DISPLAYS: 650000-8deffe

search for value of unknown: range 5b6e40-7b6e40
DISPLAYS: 5b6e40-8d5e3e

As you can see... it's a MESS. This didn't happen MOST in older versions, and there is DEFINITELY an issue, regardless of what reason you use to justify it. If it doesn't work, it doesn't work, it's that simple. So I'm sorry to disagree with you, but it is NOT working right.

Of course bro, I recommend putting away the gun, and just sitting down and looking and seeing if you can fix it. Because you know how much I love your tool, but this makes it almost impossible for me to use it for searching purposes. Which luckily for the moment I'm not doing as much as normal.

I can even make a video of it and show it to you if you have doubts bro. If I can be of assistance let me know and I can jump on aim, msn, or yahoo and relay info to you.

P.S. I'm using 4.0.0.13 pro. The one you put in the crashing thread that is said to be fixed.

EDIT: one more thing I should point out... every time I close MHS, I have to go to task manager and endtask it... or it is still in there running and slowing down my computer. And I'm using winxp, this never used to happen with older versions.

[L. Spiro]

Great. Then it may not deal with compressions, which means it may actually be possible to fix.

Except that you are the only one who gets these errors.

Nothing in the searches changed that would cause any errors.
Try “Anything Readable”.


And send me your whole MHS directory, including all scripts you aer using.
It may be some obscure script-related problem that only you get because only you are using those scripts.
You can test it by renaming DefProfile.ini and loading MHS. This resets everything. After testing you can put back your old DefProfile.ini.


L. Spiro