On 03/13/2013 05:18 PM, Mateusz Viste wrote: BTW, do you had the occasion to test Gopherus on the crashing PC? If Gopherus runs fine there, then at least I will be confident that rewriting the FDNPKG HTTP stack will solve the issue :) (but if Gopherus would crash also, then it would mean that the bug might be in Watt32 or in the way I use it) ciao! Mateusz On 03/13/2013 02:40 PM, Mateusz Viste wrote: Hi, Thanks! With your latest screenshot I see that the crash happens in fact not in FDNPKG, but somewhere in the downloader I'm using (HTGET). Altough it's hard to know why it happens exactly, because the traceback that is displayed on screen don't point to any real function, but to an internal memory management area, which makes it tricky to understand what's going on. Anyway, I think that it will be much easier for me to write my own downloading module instead of debugging HTGET. It can take me some time to do it, I will let you know when I'm done :) Your problem might also be related to some bad RAM chips (bad RAM chips can cause many funky bugs) - it's unlikely, but still, just to be on the safe side, could you please perform a memcheck on the crashing computer, to be sure nothing is wrong with it's RAM? Here is a good memory checker that you can start from DOS: http://www.majorgeeks.com/AleGr_MEMTEST_d2711.html about FDNPKG: yes, it's 32 bit. That's mainly because it's running in protected mode (which makes it safe that it won't erase your hdd or damage anything if it crashes), and it requires a few MiB of RAM to perform its package database operations (accessing more than 640K in non-protected mode is really painful). cheers Mateusz