Bug fixed (hopefully)
I never got the harddrive tab working reliable. Adding a new harddrive with the gui always resulted in a TLSF memory allocation error and I had no idea, why. The pool was damaged somewhere..
So I searched and debugged for .. many hours. Too many, so I always stopped hunting for the bug after maybe 5 hours and gave up. And restarted weeks later. And restarted.. and the last start was finally successful :-).
The gui in that AROS WinUAE-port is quite different from an "usual" zune gui: It is not created at once, but added with single calls gradually, as the gui is built by the original WinUAE gui sources and some glue code (remember gtk-mui? now the same happened with the windows gui tollkit ;-) ).
So it calls MUIA_List_Format no only once or twice, but in one place more often than 6 times, enlarging the format by 1 every time. Until 6 everything was fine, 7 it crashed. When I discovered this yesterday, I had at least a reproduce-able crash. And today I think I found the culprit: In the AROS list.c code some memory was not cleared in ParseListFormat, before using it. And so it happened, that there was no terminating NULL pointer at the end of one array, but some garbage.. which caused the crash most likely.
After adding MEMF_CLEAR, it finally seems to be reliable: