Thank you for your reply.
I reinstalled the system and fixed the bug. In order to reproduce this bug, I built a virtual machine of windows 10.
Test record
Test 1: single thread, normal operation, simple program
Test 2: dual thread, normal operation, simple program
Test 3: single thread, normal operation, simple program
It proves that the source of the bug does not start a simple video player for multithreading.
Sorry, this is my misunderstanding of the cause of the bug.
Therefore, I further tried to reproduce the bug with the original video player.
The header file of EasyX. H is attached
Test 4: single thread, normal operation, original program
Test 5: dual thread, simple program and original program. normal operation
Test 6: single thread, original program, normal operation
Test 7: dual thread, original program, normal operation
Test 8: single thread, original program, normal operation
Test 9: single thread, simple program, normal operation
Test 10: single thread, enable render (PIN) of the original program, and display normally
Test 11: dual thread, one side of the simple program, one side of the original program, normal operation.
Test 12: dual thread, original program, normal operation.
Test 13: single thread, the original program, enable render and renderfile at the same time, and run normally
Test 14: dual thread, the original program, renderfile are all displayed normally, and render is displayed normally
Test 15: single thread, simple program, normal operation.
After several possible tests, sorry, I can't reproduce the bug in the virtual machine at present.
The only details I can provide now:
During the existence of the bug, the playback task of calling renderfile or render for the first time will not play the picture, but the subsequent playback tasks will display normally,
The exception window created by renderfile will occur when the window is moved in debug mode
Nvd3dum. H (x86) / nvd3dumx. H (x64) / access conflict exception of c0000005 accessing 00000000 (1player only) / 0000011e (when2players) / 0000000000000000 (x64) / at position.
This problem may be a bug caused by a system error with a small probability. I would appreciate it if someone could explain it in detail. All tests are run on the virtual machine, which may be different from the physical host.