I am trying to record an RTMP stream with JMR, but after some time the program terminates in the middle of the recording. After the crash the system is left with no internet connection.
I have been using JMR to record streams from “hos.com” site for quite some time without problem. Since I have rebuilt my Windows 10 Pro x64 system from scratch with a Windows 1809 iso image, the program sometimes terminates in the middle of a stream recording. For information I have other systems (also rebuild from scratch with 1809 or 1803 images) where JMR records perfectly and completely the exact same HOS stream.
Based on topic described here https://support.jaksta.com/support/discussions/topics/6000013417/page/last#post-6000031821 I have modified the advance properties of my “Intel 82579V Gigabit Network Connection” like this: “Large send offload V2” are set to “disable” for IPv4 and IPv6. And in JMR settings -> Internet download -> Advanced -> Site Specific -> I have added “hos.com” with file extension flv.
The recording of the stream starts correctly but after some times (sometimes after few minutes, sometimes after 30-50 mn, sometimes never) the program terminates. As JMR terminates abnormally it keeps the usage of a proxy server activated with address http://https=127.0.0.1 and a random port. Normally this proxy is deactivated when JMR terminate the auto recording but after the crash it is not possible to reach internet (proxy stuck with probably WinPcap not driven by JMRP).
I have therefore turned the “debug mode” of JMR to “on” (with “include network trace” to “off”). Unfortunately, (or fortunately), when JMRP is in debug mode the program almost never crash!?
If I look at
historical events in the Windows event logger, I can find several events
corresponding to jmrp crashes. For example:
Nom de l’application défaillante jmrp.exe, version : 126.96.36.199, horodatage : 0x5c077266 Nom du module défaillant : ntdll.dll, version : 10.0.17763.194, horodatage : 0xf3450dbf Code d’exception : 0xc0000374 Décalage d’erreur : 0x000e0e23 ID du processus défaillant : 0x38c0 Heure de début de l’application défaillante : 0x01d4bb9b41f39913 Chemin d’accès de l’application défaillante : C:\Program Files (x86)\Jaksta Technologies\Jaksta Media Recorder 7\jmrp.exe Chemin d’accès du module défaillant: C:\Windows\SYSTEM32\ntdll.dll ID de rapport : f40193aa-72c2-4ef4-88b0-1bd751d7bb16 Nom complet du package défaillant : ID de l’application relative au package défaillant :
Note that I have also been able to record the complete one-hour program in normal mode without JMR crashing. Sometimes just recording a second time the stream after a crash works! It is therefore very difficult to reproduce the problem.
I have finally been able to crash the program in debug mode! After the crash I have zipped the file in %temp%\Jaksta as well as export of msinfo. Attached are the zip files.
This is not a critical problem as I can either record on another system or record in the failing system by turning on the debug mode. However, I would be interested to know if you have ideas about the possible source of the problem and how to fix it. I was thinking of replacing WinPcap 4.1.3 with Npcap https://nmap.org/npcap/ in compatibility mode, or Win10Pcap http://www.win10pcap.org/ (use of NDIS 6.x driver model)? I did not check recently but this may also fix the problem of the “Large send offload V2” problem?
Windows 10 release 1089 has through up a raft of issues ....
Please try npcap in compatibility mode. The next release of JMR will be distributing npcap to replace winpcap.
I have installed npcap-0.99-r9.exe and I am starting tests I'll keep you posted.
And yes 1809 is a pain … I also have HP printer drivers broken on 1809. What is strange is that it works on some system and fails on others with no obvious reasons? :O
Since I moved to npcap, I did several recordings and so far I did not have any JMRP crash.
So this may be the solution. Before closing the topic I would like to do few more tests.