STM32F103C8 resets after a couple of hours
Answers to the specific questions asked:
You asked several questions. Based on the available information at the moment, here are my responses.


Do you have any suggestions about hardware or program?

As raised in the comments under the question, concerns about your firmware triggering a fault (which, unless you add your own individual handlers, are typically escalated to become a &quot;hardfault&quot;) are understandable. I've debugged my fair share of those.
However, you said this:

[...] the main problem is that MCU resets after a couple of hours and stays at reset mode until I disconnect the board from the power supply. If I power the board immediately after disconnecting, MCU will not work but if I power the board a few minutes later, the MCU works properly just for a couple of hours [...]

(My emphasis above)
If, as you describe, you have different behavior depending on how long power has been removed from the MCU, that points clearly towards a hardware problem.
After a power-on reset, the firmware doesn't know how long power was removed, and so it should not behave differently depending on that. However, there are some hardware problems where it does make a difference how long power was removed. Hence this is why a hardware problem is strongly indicated by your description.


What should I do with the reset pin? (Currently, I'm pulling up nRST pin with a 10 kOhm resistor.)

The nRST pin has an always-enabled internal pull-up to Vdd. An external 10 kΩ pull-up should not be needed, but nor can I see how it would cause the symptoms you describe
There is an easy test, of course - disconnect (unsolder &amp; remove) that pull-up resistor and re-test. I expect that this change on its own, will not change the symptoms of the MCU hang after a few hours.
Unless you add an external reset switch (and then adding a debounce capacitor is recommended), leaving nRST disconnected is valid.
You can see nRST has no external pull-up in the Getting started with STM32F10xxx hardware development reference design.


Can this happen because of the wrong power-up sequence on VDD, VDDA, and nRST pins?

No - or at least, I don't see how that could cause the described symptoms only after a couple of hours, as you describe. Also, in comments (now chat) you explain that you have checked that VDD does not rise quicker than VDDA (which is correct). So unless you have new information not yet mentioned, it's unclear why you have that hypothesis.
nRST is both an input and output. During power-up, you can (and should) check that nRST goes high after short delay (assuming you are not pulling it down externally).


Is this similar to a clock malfunction?

If your code configures the MCU to use the HSE (external 8 MHz crystal, according to the schematic), and you don't configure and add the necessary code to use the CSS (clock security system), and that HSE clock stops after some time - then yes, that could cause the MCU to behave in the way you are seeing.
You have not mentioned any change in this part of the design, between the previous boards which did work correctly, and the new boards which show the &quot;hanging&quot; problem you describe. So again, it's unclear whether you have some reason to make this hypothesis.
It's easy to test this possibility: Change your code (as little as possible) to use the HSI (internal 8 MHz RC oscillator) instead of the HSE, and re-test. If the MCU hanging problem is not then seen, and that is the only change in the test, that points towards a problem with the HSE.
Another option would be to add the necessary code to output the HSE clock to the MCO pin (PA8). You should desolder your resistor R24 which is connected to pin PA8, if you decide to follow this plan. Then monitor the waveform on that MCO pin when using the HSE, before and after the time when the MCU hangs. Is it still oscillating correctly at the expected frequency when the MCU hangs? (Don't try to use a scope to try to view the waveform on the crystal itself.)

Troubleshooting
You seem to have a reproducible problem (albeit after a couple of hours of testing) and there are many troubleshooting approaches you could try.
Debugging using a hardfault handler could be tried (as commented). If you find the cause to be a bug in your firmware, then obviously my analysis above is wrong!
FYI, if you get strange debugger behavior, that might be another indication of a hardware problem. Hardware problems can cause other symptoms, that might incorrectly point towards firmware bugs e.g. bus faults.
If I was in your position, I would apply the Kepner-Tregoe Analytical Troubleshooting approach, specifically their Problem Analysis technique, building the &quot;IS / IS NOT&quot; table using information you have (or gathering that information) about the What, Where, When and Extent of the deviation. Then, look for differences and changes between the information in the &quot;IS&quot; (affected) and &quot;IS NOT&quot; (affected) columns of the table. You can search online for people who describe that technique in detail. (+)
One way to quickly gather some data points, is to run the same firmware on similar, but known-good, hardware e.g. a professional evaluation board, or an STM32 Nucleo etc. If your code exhibits similar behavior there, then your code does have a problem. However, if I am correct in my interpretation of your symptoms, then such a test will likely not fail unless the cause is also carried across to the known-good hardware e.g. it's caused by the external power that you provide.
Another way to get some more IS / IS NOT data is to vary parameters in your test, to try to make the problem occur at a different rate (more frequently or less frequently - it doesn't matter what the change is, just that there is a change).
For example, at the moment you say that you are switching GPIO B1 at 500 kHz. Looking at the schematic, GPIO B1 is the driving the speaker SP1 in the top-right corner. (I'm not sure why you would be driving a speaker at ultrasonic frequency, but anyway...). What happens if you replace the speaker with a different load e.g. LED + resistor. Is there any unexpected change in the time it takes to reproduce the MCU hang after that change? If so, then this change is worth investigating e.g. consider whether the problem may be caused by EMI from the speaker, which is not present with the LED + resistor load is used instead.
That is just one, simple example. Without knowing your available hardware, experience etc. I can't give you a troubleshooting flowchart, but I hope the above information is helpful.
If you add more context to the question, that might also help readers e.g.

is there a previous prototype, without this problem?
are there multiple boards with this problem or only one?
are there any external connections to the board during the failing test? If so, what are they?
have you replaced the power supply?
what measurements (with DMM or oscilloscope) have you performed and can you add them to the question?
can you add a full description of your troubleshooting tests and their results so far?
can you add an MCVE version of your firmware into your question? It must be complete, but minimal code (no extra lines at all) and it must reproduce the problem on hardware that matches your schematic.


(+) I have no association with the company, other than as a very satisfied recipient of their training.