Hello
I upgraded from version: 9.3.0.51899
I run sonnarscanner on Windows 10 with Visual Studio 2022
CFamily plugin version: 6.41.2.69583
I have similar issue like this: Analyzer Exception
I tried to disable the S6495 rule, but that is already disabled
I get this error for random files, so I cannto exclude file 
I cannot share the reproducer.zip
Thanks
Endre
I see similar error code with SonarLint plugin for VS2022 on Windows 10
[ThreadId 14] DEBUG: Executing file C:\USERS\ENDRE.VASS\APPDATA\LOCAL\MICROSOFT\VISUALSTUDIO\17.0_8EC38E87\EXTENSIONS\CYKHMTFQ.KKR\lib\subprocess.exe
Args: -
Working directory: C:\Users\endre.vass\AppData\Local\Temp
Process id: 24716
[ThreadId 66] Refreshing PCH file for C:\work\test.h. PCH file location: C:\Users\endre.vass\AppData\Local\Temp\SLVS\PCH\3c91b8d5-7f74-4d5c-ad7d-7c972e7660c3\PCH.preamble
[ThreadId 66] DEBUG: Process returned exit code -1073741571
Faulting application name: subprocess.exe, version: 0.0.0.0, time stamp: 0x6699cadd
Faulting module name: subprocess.exe, version: 0.0.0.0, time stamp: 0x6699cadd
Exception code: 0xc00000fd
Fault offset: 0x00000000029738f7
Faulting process ID: 0x0x9A7C
Faulting application start time: 0x0x1DAF33CF508BF92
Faulting application path: C:\USERS\ENDRE.VASS\APPDATA\LOCAL\MICROSOFT\VISUALSTUDIO\17.0_8EC38E87\EXTENSIONS\CYKHMTFQ.KKR\lib\subprocess.exe
Faulting module path: C:\USERS\ENDRE.VASS\APPDATA\LOCAL\MICROSOFT\VISUALSTUDIO\17.0_8EC38E87\EXTENSIONS\CYKHMTFQ.KKR\lib\subprocess.exe
Report ID: 38e62466-702f-4201-a42f-2bc4b537bd40
Faulting package full name:
Faulting package-relative application ID:
Hi,
The thread you linked to shared that the bug found in that thread is fixed in recent versions but the fix was not backported to the LTA.
Since this is the case, and since you can’t share any files for further investigation on our side, it looks like your best bet is to upgrade to the current version, which is 10.6 at this writing.
HTH,
Ann
Can I check anything in the debug files to found the route of the issue? It contains lots of information from the build machine, the files, etc and throw the error full randomly
I think I cannot update the sonarqube server, because every team use same sonar server in my company … so that not too easy
Hi,
Sorry, but with an error that shows up on “random files” and no original materials to work from, I really can’t help you.
Ann
Hello again,
We updated to the latest version of SonarQube (10.7)
Updated build wrapper and sonar scanner to the latest versions
I got same error 
I downloadad the reproducer file, but it contains lots of sensitive data so I cannot send the full xz file …
Can I run sonar scanner any parameter which is doesnt log out the sensitive data (for example source code)?
Or Which file is needed? That is the most problematic file: sonar-cfamily.reproducer
Thank you
Hi,
Can you provide your analysis log, redacted as necessary?
The analysis / scanner log is what’s output from the analysis command. Hopefully, the log you provide - redacted as necessary - will include that command as well.
This guide will help you find them.
Thx,
Ann
Dear Ann
I collected the log file, how can I send for you?
Hi,
Post it here, redacted as necessary.
Ann
Hi
Ok thank you
analysis.log (62.9 KB)
Hi,
Thanks for the log. I’ve flagged this for the language experts.
Ann
Hi @Endre_Vass, and thanks for sharing the problem with us,
Unfortunately, without the reproducer tar.xz, I can only guess.
This exception basically means that the native part of the analyzer has crashed. There could be many reasons for that, and this is why looking at the reproducer is the most efficient way to identify the problem and suggest solutions.
That said, I had a quick look at the logs you shared, and one thing that stood out to me is the parsing errors the analyzer encounters while parsing system headers:
C:\Program Files (x86)\Windows Kits\10\Include\10.0.22000.0\ucrt\corecrt_malloc.h:66 - expected parameter declarator
C:\Program Files (x86)\Windows Kits\10\Include\10.0.22000.0\ucrt\corecrt_malloc.h:66 - expected ')'
C:\Program Files (x86)\Windows Kits\10\Include\10.0.22000.0\ucrt\corecrt_malloc.h:66 - conflicting types for '_calloc_dbg'
C:\Program Files (x86)\Windows Kits\10\Include\10.0.22000.0\ucrt\corecrt_malloc.h:78 - expected parameter declarator
C:\Program Files (x86)\Windows Kits\10\Include\10.0.22000.0\ucrt\corecrt_malloc.h:78 - expected ')'
C:\Program Files (x86)\Windows Kits\10\Include\10.0.22000.0\ucrt\corecrt_malloc.h:78 - conflicting types for '_expand_dbg'
C:\Program Files (x86)\Windows Kits\10\Include\10.0.22000.0\ucrt\corecrt_malloc.h:89 - expected parameter declarator
C:\Program Files (x86)\Windows Kits\10\Include\10.0.22000.0\ucrt\corecrt_malloc.h:89 - expected ')'
C:\Program Files (x86)\Windows Kits\10\Include\10.0.22000.0\ucrt\corecrt_malloc.h:89 - conflicting types for '_free_dbg'
C:\Program Files (x86)\Windows Kits\10\Include\10.0.22000.0\ucrt\corecrt_malloc.h:101 - expected parameter declarator
C:\Program Files (x86)\Windows Kits\10\Include\10.0.22000.0\ucrt\corecrt_malloc.h:101 - expected ')'
C:\Program Files (x86)\Windows Kits\10\Include\10.0.22000.0\ucrt\corecrt_malloc.h:101 - conflicting types for '_malloc_dbg'
C:\Program Files (x86)\Windows Kits\10\Include\10.0.22000.0\ucrt\corecrt_malloc.h:113 - expected parameter declarator
C:\Program Files (x86)\Windows Kits\10\Include\10.0.22000.0\ucrt\corecrt_malloc.h:113 - expected ')'
C:\Program Files (x86)\Windows Kits\10\Include\10.0.22000.0\ucrt\corecrt_malloc.h:113 - conflicting types for '_msize_dbg'
C:\Program Files (x86)\Windows Kits\10\Include\10.0.22000.0\ucrt\corecrt_malloc.h:126 - expected parameter declarator
C:\Program Files (x86)\Windows Kits\10\Include\10.0.22000.0\ucrt\corecrt_malloc.h:126 - expected ')'
C:\Program Files (x86)\Windows Kits\10\Include\10.0.22000.0\ucrt\corecrt_malloc.h:126 - conflicting types for '_realloc_dbg'
C:\Program Files (x86)\Windows Kits\10\Include\10.0.22000.0\ucrt\corecrt_malloc.h:141 - expected parameter declarator
C:\Program Files (x86)\Windows Kits\10\Include\10.0.22000.0\ucrt\corecrt_malloc.h:141 - expected ')'
C:\Program Files (x86)\Windows Kits\10\Include\10.0.22000.0\ucrt\corecrt_malloc.h:141 - conflicting types for '_recalloc_dbg'
C:\Program Files (x86)\Windows Kits\10\Include\10.0.22000.0\ucrt\corecrt_malloc.h:154 - expected parameter declarator
C:\Program Files (x86)\Windows Kits\10\Include\10.0.22000.0\ucrt\corecrt_malloc.h:154 - expected ')'
C:\Program Files (x86)\Windows Kits\10\Include\10.0.22000.0\ucrt\corecrt_malloc.h:154 - conflicting types for '_aligned_malloc_dbg'
C:\Program Files (x86)\Windows Kits\10\Include\10.0.22000.0\ucrt\corecrt_malloc.h:161 - expected parameter declarator
C:\Program Files (x86)\Windows Kits\10\Include\10.0.22000.0\ucrt\corecrt_malloc.h:161 - expected ')'
C:\Program Files (x86)\Windows Kits\10\Include\10.0.22000.0\ucrt\corecrt_malloc.h:161 - conflicting types for '_aligned_offset_malloc_dbg'
C:\Program Files (x86)\Windows Kits\10\Include\10.0.22000.0\ucrt\corecrt_malloc.h:177 - expected parameter declarator
C:\Program Files (x86)\Windows Kits\10\Include\10.0.22000.0\ucrt\corecrt_malloc.h:177 - expected ')'
C:\Program Files (x86)\Windows Kits\10\Include\10.0.22000.0\ucrt\corecrt_malloc.h:177 - conflicting types for '_aligned_offset_realloc_dbg'
C:\Program Files (x86)\Windows Kits\10\Include\10.0.22000.0\ucrt\corecrt_malloc.h:186 - expected parameter declarator
C:\Program Files (x86)\Windows Kits\10\Include\10.0.22000.0\ucrt\corecrt_malloc.h:186 - expected ')'
C:\Program Files (x86)\Windows Kits\10\Include\10.0.22000.0\ucrt\corecrt_malloc.h:186 - conflicting types for '_aligned_offset_recalloc_dbg'
C:\Program Files (x86)\Windows Kits\10\Include\10.0.22000.0\ucrt\corecrt_malloc.h:196 - expected parameter declarator
C:\Program Files (x86)\Windows Kits\10\Include\10.0.22000.0\ucrt\corecrt_malloc.h:196 - expected ')'
C:\Program Files (x86)\Windows Kits\10\Include\10.0.22000.0\ucrt\corecrt_malloc.h:196 - conflicting types for '_aligned_realloc_dbg'
C:\Program Files (x86)\Windows Kits\10\Include\10.0.22000.0\ucrt\corecrt_malloc.h:204 - expected parameter declarator
C:\Program Files (x86)\Windows Kits\10\Include\10.0.22000.0\ucrt\corecrt_malloc.h:204 - expected ')'
C:\Program Files (x86)\Windows Kits\10\Include\10.0.22000.0\ucrt\corecrt_malloc.h:204 - conflicting types for '_aligned_recalloc_dbg'
C:\Program Files (x86)\Windows Kits\10\Include\10.0.22000.0\ucrt\stdio.h:425 - expected parameter declarator
C:\Program Files (x86)\Windows Kits\10\Include\10.0.22000.0\ucrt\stdio.h:425 - expected ')'
C:\Program Files (x86)\Windows Kits\10\Include\10.0.22000.0\ucrt\stdio.h:425 - conflicting types for '_tempnam_dbg'
C:\Program Files (x86)\Windows Kits\10\Include\10.0.22000.0\ucrt\stdio.h:2421 - expected parameter declarator
C:\Program Files (x86)\Windows Kits\10\Include\10.0.22000.0\ucrt\stdio.h:2421 - expected ')'
C:\Program Files (x86)\Windows Kits\10\Include\10.0.22000.0\ucrt\stdio.h:2421 - conflicting types for '_tempnam_dbg'
C:\Program Files (x86)\Windows Kits\10\Include\10.0.22000.0\ucrt\stdlib.h:1201 - expected parameter declarator
C:\Program Files (x86)\Windows Kits\10\Include\10.0.22000.0\ucrt\stdlib.h:1201 - expected ')'
C:\Program Files (x86)\Windows Kits\10\Include\10.0.22000.0\ucrt\stdlib.h:1201 - conflicting types for '_dupenv_s_dbg'
C:\Program Files\Microsoft Visual Studio\2022\Professional\VC\Tools\MSVC\14.39.33519\include\cstdlib:45 - no member named 'calloc' in the global namespace
C:\Program Files\Microsoft Visual Studio\2022\Professional\VC\Tools\MSVC\14.39.33519\include\cstdlib:48 - no member named 'free' in the global namespace
C:\Program Files\Microsoft Visual Studio\2022\Professional\VC\Tools\MSVC\14.39.33519\include\cstdlib:51 - no member named 'malloc' in the global namespace
C:\Program Files\Microsoft Visual Studio\2022\Professional\VC\Tools\MSVC\14.39.33519\include\cstdlib:57 - no member named 'realloc' in the global namespace
Parsing errors can occasionally cause the parser to go into an invalid state, increasing the likelihood of a crash. The errors above might have been caused by some includes before corecrt_malloc.h that add conflicting function declarations. However, without the reproducer, it is really hard for me to know how we ended up with these errors.
You can check if the problem is reproducible on a new project that uses the same MSVC toolset version, and try to include the same set of headers as your current project. If you find it is reproducible, then you can generate the reproducer on the new project and share that one to avoid sharing sensitive data from the original project.
I hope this helps, and let me know if you would like to open a private thread with you if you are willing to share any additional details in private,
Best regards,
Michael
Dear Michael,
I tried with my base library, but at the first file, I got same error … but I didnt see the corecrt_malloc.h errors
I tried to reproduce it, with an “empty” project (includes system includes) but it works without any issue
analysis.log (7.5 KB)
Hi @Endre_Vass,
Thanks for sharing, this means that my guess above about the parsing errors being related is incorrect. 
Unfortunately, it is very hard for me to think about any additional guesses given only these logs. It would be very helpful if you can share the reproducer privately; I already started a thread.
Otherwise, I can only suggest trying to reproduce on the new “empty” project by changing the settings/code, …etc.
Best regards,
Michael
Hi
Yes, now I try to comment out includes in the original source, and now I found which file is the problematic. It’s contains two #define , now I try to check what is the problem
Hi
I found the error, try to share the exact code, but … I have similar
#pragma once
namespace ns {
class MyCls {
private:
constexpr const uint64_t value = UINT64_MAX;
public:
template<int IDX>
constexpr uint64_t func1();
template<>
constexpr TypeInfoID_dh func1<-1>();
template<size_t SIZE>
constexpr uint64_t func2();
template<size_t SIZE>
constexpr uint64_t func2();
};
template<int IDX>
constexpr uint64_t MyCls::func1()
{
}
template<>
constexpr TypeInfoID_dh MyCls::func1<-1>()
{
return value;
}
template<size_t SIZE>
constexpr uint64_t MyCls::func2()
{
return func1<SIZE - 1>() ^ value;
}
template<size_t SIZE>
constexpr uint64_t MyCls::func2()
{
return func1<SIZE - 1>() ^ value;
}
}
AND THIS version works:
#pragma once
namespace ns {
class MyCls {
private:
constexpr const uint64_t value = UINT64_MAX;
public:
template<int IDX>
constexpr uint64_t func1()
{
}
template<>
constexpr TypeInfoID_dh func1<-1>()
{
return value;
}
template<size_t SIZE>
constexpr uint64_t func2()
{
return func1<SIZE - 1>() ^ value;
}
template<size_t SIZE>
constexpr uint64_t func2()
{
return func1<SIZE - 1>() ^ value;
}
};
}
So if the code are outside of the class definition, the scanner crash, but I change the name of the constexpr ‘value’, it works 
but ofc, cannot compile the code…
That is a header file, so I cannot exclude from the check Can you help me?
Hi @Endre_Vass, and thanks for sharing the example,
I might be missing something, but the code you shared in the first snippet doesn’t compile as it has multiple declarations of func2. Analysis works fine though when I remove the duplicated definitions and add the necessary headers. See this Compiler Explorer link.
For me, this doesn’t necessarily imply that this is the root problem causing the crash; Changing something like that can influence the paths taken by the parser indeed, so that it doesn’t hit the crash, but this doesn’t mean that the problem lies in the way member functions are parsed out of the class.
To prove this, you can take the anonymized snippet you shared, paste it in a new empty MSVC project, and add the necessary headers/configuration to make it build. Does analysis crash on that new project? If so, you can share the reproducer with us, and this would enable us to track the issue further on our side.
I hope this helps,
Best regards,
Michael
Hi
I tried to reproduce it on a small project, but the small project works.
It have multiple pahse of the problem but fixed if I change the code and move the functions into the class … I try to share more information
Thanks @Endre_Vass for sharing the logs and the reproducer files,
This turned out to be CPP-5626. This was already fixed in CFamily version 6.60 (currently available on SonarCloud, and will be available on SonarQube 10.8 - expected around the beginning of December).
A workaround to unblock the analysis was also shared with the user…
Best regards,
Michael
Thank you very much!