Is that (unloading and reloading the dll) standard procedure when calling repeatedly run time linked dll's,

No. This is definitely not SOP.

If doing so is actually free up sufficient memory to make a substantial difference to your application, you ought to be able to see that quite clearly reflected in the memory usage graph/numbers in the Task Manager or Process Explorer. But then, if that were the case, I would have expected you to be a lot more positive than "probably shows that there is a memory leak." & "This probably shows that the dll is not releasing memory"

It could be that calls into the dll are allocating memory or objects that users of the dll are meant to free themselves, but I'd expect that to be relatively obvious from the API documentation.

Another common possibility is that the dll was built using a different runtime library to that of the Perl build you are using, and that is the source of the problem. But again, it should be fairly easy to identify this using Process Explorer.

Were I attempting to debug this, the first thing I do is compile a 10 line C app that calls the same APIs in the DLL in a loop and see what happens. If the hang still occurs, then it will become clear that the problem is in the dll.

If not, then I'd try shifting from using Win32::API to Inline::C to try and isolate that possibility.

But both those require you have access to both the DLL and a compiler.

There's not much more than can be suggested without lots more information.