[Windows CE] Debug is normal, and release is abnormal. Have you met?

I met it, but I also encountered it multiple times. once plagued for a long time, I finally solved the issue one by one. looking back, the problem is not as much as you think. If you can keep a mind to think at the beginning, you don't have to spend that long.

Gets stuck. Continue to update it next time.

OK. Go on.
In addition to some mistake errors caused by # ifdef debug, timing is the most common problem.

Some people say: In debug, it is slow, and release is fast. Why are there different time sequences?
A: That's right. It's true that everyone is getting faster, but the pace is not necessarily the same!

In debug, many codes are hidden due to various Serial Output and the kernel of DEBUG Versions. it seems to be normal, but it is not. for example, the last problem I encountered was that a and B had to access a resource (CSPI) at the same time and in different process spaces, mutex was required for resource access protection. A first initializes CSPI (cspi_a configuration) and then performs some operations using CSPI. then initialize B, and insert B to obtain the CSPI control permission and reconfigure CSPI (cspi_ B configuration ). at this point, if a wants to access CSPI, it can only stare at B. so, if you want a to continue to do it next time, B should restore the CSPI configuration after completing its own tasks. in this way, a can proceed without knowing it. at that time, my mind was short-circuited, and the Code for Restoring Process configuration B was not placed in the mutex protected area !!! However, such code is normal under debug, and release finds it abnormal.

Fortunately, this error is obvious, and the code is all in one piece. You can find it wrong after careful review. Then the next problem is not so obvious.
Serial Port sending and receiving is a classic mutual problem (md, and .. because it is in the same process (device.exe), so you don't need mutex, just use critical_section. in fact, the cause of the problem is that the critical value protection is inappropriate. the idea of author is correct, but it is obviously confusing to handle countless errors in the sending function. the direct cause is that all the normal sequences in the release cannot be reached in the release. it took a long time to find the cause. Now we can sum up the two reasons: 1. I. I always think that the part of the code I wrote has errors. II. Lack of experience. failed to push in the correct direction.

These problems have been solved, and I have some feelings about the suspend problem that I have been tossing some time ago:
1. Problems are generated with clues. Finding a weapon often begins to solve the case;
2. Do not trust any code or reject any of your abilities;
3. It is best to solve the problem, but the exception handling mechanism should be improved beforehand.