Back then I tried to download straight to my internal drive, and it kept crashing the same; and there are no issues at all regarding the networks cables, the internet connection itself is working properly on both systems.

I have my doubts regarding it being crashing because faulty drivers and/or hardware related issues, since it was doing it in two way different systems the same way.

Anyway, since my last message I kept and still am downloading fine, and there were crashes neither stuck downloads whatsoever. I only keep updating JD2 and using it the same way as before, so I don't really know what was going before.

Hello, I'm getting the random crashes again, but this time on a completely new PC and on Windows 10 1809, x64, LTCS.

10.04.19 11.49.48 <--> 10.04.19 05.27.39 jdlog://3709776935451/

JD2 crashes out of nothing, after being sometime downloading.

I titled "2", because sometime ago I had a similar problem, but it was on another Windows 7 PC. Somehow it was fixed over there, but it wasn't clear exactly which one was the problem. The only difference I see with that setup so far, is the amount of memory and the java version reported by JD2 aren't the same:

Please check your JDownloader folder for a hs_err file. In case Java crashes, such a file should be created and contain more information about the crash.
By crash you mean 'close itself/gone' and not freeze, right?

At first I thought it was related to using a 20/16 threads/connections configuration, so I tried again with 8/8, but it still crashes. And by crash I mean JD2 closing itself after being downloading for a while (~20'), and showing an information message with red letters, about the crash cause/s.

Each time it is opened after being crashed and I start downloading again, some of the files get a "File already exists" error message, despite they being around %90 of progression. But then, when I open the files, they were really finished.

I have increased the memory value to "-Xmx1g", resulting in this values:

Usage: 390.69 MB - Allocated: 545.83 MB - Max: 989.88 MB

Since now I have 32 GB from system memory, you tell me if that would be a correct/ideal value.

After modifying that java related parameter, JD2 kept crashing the same way as before, but it no longer writes the error log. Here I leave you a log of when JD2 crashed like this:

11.04.19 01.14.44 <--> 11.04.19 01.06.36 jdlog://5529776935451/

While it downloads, I saw some of the files stop/start several times, continuing from were they stop; besides, some seconds before crashing, some message about the zippy plugin needing to be restarted shows up.

OK, I'd been replicating the issue a few more times, and was able to get the log. By the way, I generated this log ID:

11.04.19 00.50.20 <--> 11.04.19 01.38.14 jdlog://3169776935451/

Between that time frame, there was this "special" occasion when JD2 behaved the same way as with the previous crashes, but instead closing itself, it just made the downloads related functions get frozen; the program itself kept working, I have even made some "update check", could switch between windows, use contextual menu options, etc. but not those related to the "download" process itself: reset, stop, force download start, etc.

The crash happend without any hint what might have cause it.
I would recommend to scan memory with memtest86
Have you installed a VPN tool? some are known to crash network stack. In case you're using the vpn tool, please try without vpn connected/enabled

I did a fresh Windows 10 installation some days ago, and installed a few programs so far, but no VPN. The only network related application I have installed is "Du Meter", and already did some long CPU/Memory tests after building up the system, without any errors.

Well, since my last message I started trying a "fresh" 64 bit version from JD2 among different settings, and weirdly enough, I have no crashes anymore.

I tried with the old configurations, different java versions, different amount of threads/connections, etc. and no crashes so far. And I don't remember doing any "crucial" change to my system, other than a NVIDIA's driver update.

Hopefully it stays like this, but I think sudden crashes that get "fixed" automatically like this are still something to concern about, so I will not think of it as a "definitively" closed case.

Although I'm not using JD2 since several days now, since my last test I kept getting some stability problems with my new PC, so I decided to do some tests with "Windows Memory Diagnostic" and MemTest86 tools. The tests failed.

Long story short, after days of a big amount of different tests with the memory sticks, I came to the conclusion than neither the modules nor the sockets themselves are defective, but it seems with my particular womanboard I couldn't use the four sticks at once along with the default "XMP" 3000 MHz profile, otherwise I will get crashes and/or other kind of weird related problems. But even with a lower non-oc "2933" MHz value, it keeps giving troubles, so I blame basically the BIOS being the culprit here. Paradoxically, I found out that using a "3200" MHz auto OC profile, things get stable, and memory tests pass OK. So, let's hope it keeps this way.

Well, all kind of started when I remember having this problem out of nothing, and then other related ones, like sporadic corrupted downloads, a "the memory could not be written" message and even some crash with a ""Irql Not Less or Equal" message, a few seconds later after starting the system with the memory running at "2933 MHz" (they have a 3000 MHz stock rate). If I run it with the highest "non-OC" value that my woman-board admits, I still get an unstable system, which sometimes even reverts back to "2133 MHz" frequency automatically after some restart. It was all fine running it with the "XMP 3000 MHz" profile while I had just "2" memory sticks installed, but the problems started when I added two additional ones. The system remained stable almost all the time, but it never passed the WMD's checks neither the MemTest86's ones, although with this last one, there was one time when a 4 passes, ~8 hours long test finished correctly. So, since I don't wanted to keep using an "almost" stable brand new system, I decided to do all the relevant tests.

woman-board's technical assistance people told me about they couldn't bring support to people who used their products to do OC, since that kind of use wasn't contemplated by the warranty. That's just fine to me, but the thing is, I never planned to do any OC at all, but due to the aforementioned issues, I'm kind of "forced" to do it now.

Using the "XPM 3000 MHz" profile, I usually kept hearing an additional short "beep" at POST's time, which seems to be related to a "DRM Refresh Failure" issue; there was some other short beep as well, which randomly appeared while already using Windows. I don't hear none of them anymore since I'm using the "EZ Overclock Tuner's" 3200 MHz (1,35>1,38 V) preset profile; memory tests pass and no more random crashes as well, at least so far. So, most probably it is a firmware's related issue, which hopefully they fix soon.

A few days after my last comment, I ended up realizing my system wasn't really stable, but an "almost" stable one; since even when in a less frequent way, I kept getting memory related problems. Nevertheless, I decided to remain using the four memory modules at once, and continued like that for a few more weeks, till I saw my womanboard's brand posted a "significant" firmware update. And despite the change log mentioned just a new AGESA's version which supports newer 3rd generation Ryzen CPUs, it somehow improved my system's performance as well.

The thing is, it was indeed a firmware related problem (and it still is), since after applying the last version, I finally got a really stable system (no more errors at all); although I'm not running the memories at their "XMP" profile ideal speed rates "15-17-17-35 CR1, 3000 MHz, 1,35V ", but with some slightly lesser "manual" values at "15-17-17-35 CR2, 2933MHz, 1,35V".

So, the moral of this story is about being "quite" attentive when picking up memory modules for 2nd and I bet even the new 3rd Ryzen CPU, since it's not all that straightforwardly as when assembling "Intel" based systems; contrarily, with AMD's platforms one should strictly "stick" to one of the specific womanboard's "QVL" memory modules' use. I learned up the lesson after building my first AMD's system ever, regrettably.

P.D.: For some weird reason, the board censors the "m-o-t-h-e-r" word, replacing it by "woman".