Why Visual Studio Debugging HashTable Differs from IIS

Question

I have a very curious thing happening in my application with HashTables.

First: Yes, I know that HashTables are not supposed to be ordered as they were inserted, or in any other way (but with a hash of keys). This does not answer my question. I don’t need this, I just want to know WHY it differs from two seemingly identical systems.

So there it is. The left side is the IIS order, the right is Visual Studio.

Why is it different? Given that .NET should (?) Use the same algorithm to store and return data from a HashTable, the order should be the same on both sides, right?

If, as I found out, the hash key is hashed, then this hash must be the same on both systems, which leads to the same order of hashes (keys) and, therefore, the same order of data in the hash table.

Where am I mistaken? What is the difference in implementing a HashTable between IIS and VS?

A few comments from the comments:

• The project is for .NET 4.0
• IIS uses .NET 4.0 for the application pool.
• I actually copied the compiled binaries from the Visual Studios bin folder to the IIS folder, so they are exactly the same
• My guess is that IIS uses the same .NET implementation as Visual Studio. If not: why? And what makes hashing on IIS so different from what is in Visual Studio?

Answer 1

As @usr helped me, the reason for this behavior is the GetHashCode () function, which is used as the base for the HashTable key. Depending on the key, the iteration order over the HashTable will be different.

A hash function should usually return the same hash for each input, but ... this function returns different hashes depending on the configuration parameter, namely <UseRandomizedStringHashAlgorithm> , which returns another hash created by the mysterious function InternalMarvin32HashString () .

A warning was issued to prevent a DOS attack attack on Hash Flooding.

However this function

[...] is imported from an external DLL, clr.dll, to be exact.

from Martin Beble December 14, 2012

Thus, we cannot really know what he is doing exactly, without any basic (possibly even illegal) refactoring.

Answer 2

In order for the elements in the table to be in the same order, several conditions must be met:

• The hash algorithm must be the same. This means not only a hash function, but also a way to grow the table, compress, handle collisions, etc. This is probably the reason in your case (different algorithms).
• The environment must be the same. It makes sense if one of the parameters of the hash algorithm is something from the environment, for example, available memory. Some algorithms are quite complex, trying to avoid page skips or overlay a table on security for security reasons.
• The data must be the same and stored in the hash table in the same order.