| Author |
 Topic  |
|
|
Jackie
Junior Member
China
12 Posts |
 Posted - Jul 14 2026 : 06:30:13 AM
|
No matter how long I wait, it stays stuck like this, completely maxing out a CPU thread. It seems to be caught in an infinite loop. Even after I close Visual Studio, the process fails to exit automatically. It just lingers in the background, constantly running and causing the fans to spin at full speed.
callstack:
0, valibclang2.dll!B73B66FC925D43BCB6104819DEFC3A32+0x7a3052, 0x558f2132
1, 0x100fbb2a1, 0x100fbb2a1
2, 0x559250c908fce7d8, 0x559250c908fce7d8
3, 0x8fce7d8cfe8c702, 0x8fce7d8cfe8c702
4, 0x17900000000, 0x17900000000
5, 0x8f1ddf0cfe8cf22, 0x8f1ddf0cfe8cf22
6, 0x8fcedc855c83e6e, 0x8fcedc855c83e6e
7, 0x8fce7d800000001, 0x8fce7d800000001
8, 0x543003f00170016, 0x543003f00170016
9, 0xfbb2a1558dde60, 0xfbb2a1558dde60
10, 0x79a8d8800000000, 0x79a8d8800000000
11, 0x17b00000000, 0x17b00000000
12, 0x17a, 0x17a
13, 0xfbb2a100000000, 0xfbb2a100000000
14, 0x79a8d94, 0x79a8d94
15, 0x79a8d98, 0x79a8d98
16, 0x79a8da808fce7e0, 0x79a8da808fce7e0
17, 0x8fce7d8, 0x8fce7d8
18, 0x5435f1808fce7d8, 0x5435f1808fce7d8
19, 0x79a838808f1ddf0, 0x79a838808f1ddf0
20, 0x84d7008553987b0, 0x84d7008553987b0
21, 0x8f1ddf008f1ddf0, 0x8f1ddf008f1ddf0
22, 0x79a848805435f18, 0x79a848805435f18
23, 0x55c7b56d55c7b26e, 0x55c7b56d55c7b26e
24, 0x8f1ddf0cfe8cf7a, 0x8f1ddf0cfe8cf7a
25, 0x5435f1805435f18, 0x5435f1805435f18
26, valibclang2.dll!B73B66FC925D43BCB6104819DEFC3A32+0x7a3052 (No unwind info), 0x558f2132
27, valibclang2.dll!B73B66FC925D43BCB6104819DEFC3A32+0x7cff27 (No unwind info), 0x5591f007
28, valibclang2.dll!B73B66FC925D43BCB6104819DEFC3A32+0x7d1fc9 (No unwind info), 0x559210a9
29, valibclang2.dll!B73B66FC925D43BCB6104819DEFC3A32+0x7cd971 (No unwind info), 0x5591ca51
30, valibclang2.dll!B73B66FC925D43BCB6104819DEFC3A32+0x7cd172 (No unwind info), 0x5591c252
31, valibclang2.dll!B73B66FC925D43BCB6104819DEFC3A32+0x82ea4a (No unwind info), 0x5597db2a
32, valibclang2.dll!B73B66FC925D43BCB6104819DEFC3A32+0x828551 (No unwind info), 0x55977631
33, valibclang2.dll!B73B66FC925D43BCB6104819DEFC3A32+0x827cbd (No unwind info), 0x55976d9d
34, valibclang2.dll!B73B66FC925D43BCB6104819DEFC3A32+0x82b209 (No unwind info), 0x5597a2e9
35, valibclang2.dll!B73B66FC925D43BCB6104819DEFC3A32+0x830589 (No unwind info), 0x5597f669
36, valibclang2.dll!B73B66FC925D43BCB6104819DEFC3A32+0x78ac14 (No unwind info), 0x558d9cf4
37, valibclang2.dll!B73B66FC925D43BCB6104819DEFC3A32+0x7987ec (No unwind info), 0x558e78cc
38, valibclang2.dll!B73B66FC925D43BCB6104819DEFC3A32+0x7891d5 (No unwind info), 0x558d82b5
39, valibclang2.dll!B73B66FC925D43BCB6104819DEFC3A32+0x788a8e (No unwind info), 0x558d7b6e
40, valibclang2.dll!B73B66FC925D43BCB6104819DEFC3A32+0x788570 (No unwind info), 0x558d7650
41, valibclang2.dll!B73B66FC925D43BCB6104819DEFC3A32+0x784ca5 (No unwind info), 0x558d3d85
42, valibclang2.dll!B73B66FC925D43BCB6104819DEFC3A32+0x77c4ff (No unwind info), 0x558cb5df
43, valibclang2.dll!B73B66FC925D43BCB6104819DEFC3A32+0x6dbc5f (No unwind info), 0x5582ad3f
44, valibclang2.dll!B73B66FC925D43BCB6104819DEFC3A32+0x6c9551 (No unwind info), 0x55818631
45, valibclang2.dll!B73B66FC925D43BCB6104819DEFC3A32+0x1bd66ef (No unwind info), 0x56d257cf
46, valibclang2.dll!B73B66FC925D43BCB6104819DEFC3A32+0x1c03c1a (No unwind info), 0x56d52cfa
47, valibclang2.dll!B73B66FC925D43BCB6104819DEFC3A32+0x1bd83da (No unwind info), 0x56d274ba
48, valibclang2.dll!B73B66FC925D43BCB6104819DEFC3A32+0x1bd81d1 (No unwind info), 0x56d272b1
49, valibclang2.dll!B73B66FC925D43BCB6104819DEFC3A32+0x1bd9a85 (No unwind info), 0x56d28b65
50, valibclang2.dll!B73B66FC925D43BCB6104819DEFC3A32+0x1c02d17 (No unwind info), 0x56d51df7
51, valibclang2.dll!B73B66FC925D43BCB6104819DEFC3A32+0x1ba9 (No unwind info), 0x55150c89
52, valibclang2.dll+0x2defe (No unwind info), 0x5514defe
53, VaCodeInspections.Interop2.dll!WholeTomato::VaCodeInspections::Native::interop2+0x20e04 (No unwind info), 0x59c02fa4
54, VaCodeInspections.Interop2.dll!WholeTomato::VaCodeInspections::Native::interop2+0x2221f (No unwind info), 0x59c043bf
55, ucrtbase.dll!thread_start<unsigned int (__stdcall*)(void *),1>+0x43, 0x75b359e3
56, kernel32.dll!BaseThreadInitThunk+0x19, 0x74cf7ba9
57, ntdll.dll!__RtlUserThreadStart+0x2b, 0x7714c3ab
58, ntdll.dll!_RtlUserThreadStart+0x1b, 0x7714c32f
dmp file:https://1drv.ms/u/c/8b08370db8cbf5e4/IQCj4z5d_8JXQIXki-cmBNoeATMHRit4Yg9zw9JHRReeS90?e=6Sp9CF |
Edited by - Jackie on Jul 14 2026 06:41:45 AM |
|
|
feline
Whole Tomato Software
United Kingdom
19396 Posts |
Posted - Jul 14 2026 : 07:43:08 AM
|
Interesting, and thank you for the dump file.
What are the second and third columns showing? I don't know what these numbers represent.
If you show the Code Inspection Results window, is it being populated with results?
How long does the CPU spike on code inspection last? Seconds? Minutes? Hours?
Does this spike seem to be tied to any files in particular? If I had to guess, I would expect this to be caused by a very large file that code inspection is working hard to fully parse and understand. I have a 14,000 line cpp file that is designed to produce several thousand code inspection results. The CPU usage is barely noticeable for me, so I am curious to know if you can reproduce this on demand by opening certain files. |
zen is the art of being at one with the two'ness |
 |
|
|
Jackie
Junior Member
China
12 Posts |
Posted - Jul 15 2026 : 04:18:41 AM
|
screenshot,logs and record video: https://1drv.ms/u/c/8b08370db8cbf5e4/IQA-IbDW-6_QTb2JSFHRWszWAVD-Qh8ifTqE_twv2pQLCEY?e=wL01fD
**Q: What are the second and third columns showing? I don't know what these numbers represent.**
**A:** These are screenshots from "System Informer". You can see what these columns represent in my latest screenshot.
**Q: If you show the Code Inspection Results window, is it being populated with results?**
**A:** As shown in the screenshot, it is completely empty.
**Q: How long does the CPU spike on code inspection last? Seconds? Minutes? Hours?**
**A:** Indefinitely, no matter how long I wait.
**Q: Does this spike seem to be tied to any files in particular? If I had to guess, I would expect this to be caused by a very large file that code inspection is working hard to fully parse and understand. I have a 14,000 line cpp file that is designed to produce several thousand code inspection results. The CPU usage is barely noticeable for me, so I am curious to know if you can reproduce this on demand by opening certain files.**
**A:** This happens as soon as I open my VS project, even though this project doesn't contain many files. Upon further analysis, I found that the issue occurs when parsing a file named `FarPointSpreadAccEnabler.h`.
Interestingly, when this file is opened within the `.sln` located in its parent directory, it parses perfectly fine. You can see this in the shared folder `ok when open in [FarPointSpread30Test_vs201x.sln]` (which contains screenshots and log files).
However, when I include it in a different `.sln` (via the `#include` directive) and it gets parsed, it triggers this infinite loop issue. The content of this file is actually very simple, and I have provided it in my shared files. I've documented the exact scenario that triggers the problem in the folder `bad when open in [AccEnabler.sln]`, which includes a video recording and log files. |
|
|
|
Jackie
Junior Member
China
12 Posts |
Posted - Jul 15 2026 : 04:33:35 AM
|
| Upon further investigation, I found that even within `FarPointSpread30Test_vs201x.sln`, simply switching to the `Release|Win32` configuration also triggers this issue. |
|
|
|
feline
Whole Tomato Software
United Kingdom
19396 Posts |
Posted - Jul 16 2026 : 07:32:16 AM
|
Would it be possible to get a copy of just the SLN and any VCXPROJ files that the solution uses?
Or, perhaps better yet, a copy of the generated "VaCodeInspections.log", one copy when you are using the Debug configuration, and a second copy when you are using the Release configuration?
As you already know, the code file looks really simple and very small, and it doesn't even include lots of system header files.
When you change the configuration this can change the include directories and defines, both of which are logged to "VaCodeInspections.log". I am wondering what is changing, from Code Inspections's point of view, when you change the configuration.
If you were changing the include directories, to use a different version of a system or 3rd party library, which was used by one of these two files, then that might help explain the problem you are seeing, but nothing else is being included, which is what is confusing me.
At a basic level, Code Inspection is running a clang-tidy parse of the file, and then reporting back the results to you. clang-tidy is given the file to parse, the required include directories to check, and the other compiler settings it needs to parse the file. So Code Inspection should be doing something quite isolated, and easy to study, in theory. |
zen is the art of being at one with the two'ness |
|
|
|
Jackie
Junior Member
China
12 Posts |
Posted - Jul 16 2026 : 11:13:55 PM
|
| Have you looked at the log files in the shared files? I see they contain macro definitions for project configuration, etc. If you can reproduce the problem from there, I won't need to separately organize the project configuration. |
|
|
|
feline
Whole Tomato Software
United Kingdom
19396 Posts |
Posted - Jul 17 2026 : 10:36:03 AM
|
I am getting closer to reproducing your logs. But I am currently stuck on the line:
- Flags: -target;x86_64-pc-windows-msvc15.0.0;-nostdinc
I had assumed this would come from the project properties -> General -> Platform Toolset = ...
but apparently not. Once I get this figured out, I will see how close I can get the include directory list. But some of those directories I just don't have. I would not expect them to matter, but something is triggering this bug for you. |
zen is the art of being at one with the two'ness |
|
|
| |
Topic |
|
|
|
VaCodeInspectionsServer maintained high CPU usage.
