Search for problems using the. NET/CLR stress log function

I don't know if anyone who uses. Net for development has encountered some very strange problems, but I don't know how to start it? At this time, the stresslog function provided by CLR is very useful. This stresslog can record what CLR does in many cases. For example, for a very simple. Net Program log that finally throws an exception, it is roughly as follows:

Stress log: Facilitiestolog = 0x8000ffff Leveltolog = 16 Maxlogsizeperthread = 0x20000 (131072) Maxtotallogsize = 0x2000000 (33554432) Currenttotallogchunk = 6 Threadswithlogs = 3 Clock frequency = 0.014 GHz Starting Time 22:47:37 Last message time 22:47:44 Total elapsed time 6.520 Sec Thread timestamp facility message ID (SEC from start) Bytes -------------------------------------------------------------------------------------- 1638 6.519607729: 'sync' safeexitprocesses: exitcode =-2146233082 1638 0.842361250: 'gc 'createhandle: 0000000000261338 1638 0.838161973: 'eh 'in clrvectoredexceptionhandler, exception = e0434f4d, context = 201710000001ae4c0, IP = 201710000779b649d sp = 201710000001aea60 1638 0.837840633: 'gc 'createhandle: 0000000000261340 1638 0.837838329: 'eh 'in thread: setlastthrownobject: OBJ = 0000000002b76238 1638 0.837837281: 'eh 'exception hresult = 0x80131600 message string 0x0000000002b96188 (dB will display) innerexception 0000000000000000 Mt 0000000000000000 (Bad methodtable) 1638 0.837834418: 'eh '****** managed exception thrown: Object thrown: 0000000002b76238 Mt 000007fef40fadc8 (system. applicationexception) rethrow 0 1638 0.837646265: 'classloader 'dorunclassinit: Returning success for init 000007fef40f2e10 (system. Collections. hashhelpers) in appdomain 2017100000035ccc0 1638 0.837618049: 'classloader 'runclassinit: returned successfully from class contructor for Type 000007fef40f2e10 (system. Collections. hashhelpers) 1638 0.837617141: 'classloader 'dorunclassinit: Returning success for init 000007fef40f2e10 (system. Collections. hashhelpers) in appdomain 2017100000035ccc0 ... ... (Save more than 1000 rows in the middle) ... 1638 0.328838232: 'gc 'createhandle: 00000000002613e0 1638 0.312699170: 'classloader 'attempted to set new Native file 02088e80, old file was 00000000, location in the image = f3cc1008 1754 0.269468466: 'alway' setupthread managed thread 00000000020815d0 thread id = 2 ------------ Last message from thread 1754 ----------- 1638 0.268254415: 'gc 'createhandle: 00000000002613e8 1638 0.268252879: 'gc 'createhandle: 00000000002615f0 1638 0.219663812: 'alway' setupthread managed thread quota 003b8bc0 thread id = 1 1638 0.219644256: 'gc 'createhandle: 00000000002613f0 1638 0.219643209: 'gc 'createhandle: 00000000002615f8 1d9c 0.200751492: 'cordb' always 'debugger thread spinning up ------------ Last message from thread 1d9c ----------- 1638 0.187761783: 'gc 'createhandle: 00000000002613f8 1638 0.187758151: 'gc 'createhandle: 00000000002611f8 ------------ Last message from thread 1638 ----------- ---------------------------- 625 total entries ------------------------------------

We can see that this program finally (note that the first part of the log is the last event of the program, which is the opposite) throws a system. applicationexception, HR = 0x80131600, resulting in program termination. Of course, the actual situation is much more complicated than this. Here is just an example. This information details the operation of CLR, which is mainly used by developers of CLR groups. However, this does not mean that this information is common. NET developers are useless. In fact, this information is very useful for understanding the running status of the managed program, and if errors occur during the operation, these errors will also be written to the stresslog. Of course, you may not need to use stresslog to solve the general problem, but if you have no clue to solve the problem, try stresslog, which may have unexpected results. If you want to interpret the specific information that has doubts, you can also find the corresponding code lines in the rotor code to determine the meaning of the errors. For example, in the appdomain: Unload method, you can find that the stress_log macro outputs the unload domain information:

   1: void AppDomain::Unload(BOOL fForceUnload)

   2: {

   3: …

   4:     STRESS_LOG3 (LF_APPDOMAIN, LL_INFO100, “Unload domain [%d, %d] %p/n”, GetId().m_dwId, GetIndex().m_dwIndex, this);

   5: …

   6: }

Note that not all information can be found in the rotor, because the rotor does not contain all CLR 2.0 code.

The method for obtaining stresslog is as follows:

1. Enter set complus_stresslog = 1 in the command line.

2. Start windbg in the command line, and then start to debug the program through windbg until the program runs properly.

3. Enter. loadby SOS mscorwks in windbg. This step is used to load SOS. SOS is a windbg extension used to debug CLR. I have the opportunity to write an article specifically to use SOS to debug the hosted program. This is often used by the CLR team to debug the hosted program.

4. Enter in windbg! Dumplog

5. Check the stresslog.txt file in the program startup directory. The stresslog information is in it.

Step 2 can also be found in HKEY_LOCAL_MACHINE/software/Microsoft /. netframework creates a value named stresslog of the DWORD type, which can be set to 1, but the effect is global. It is not as flexible as set complus_stresslog.