Justas with a normal project you can start debugging with F5, which will launch the EXE and attach the debugger. If you want to debug startup you can launch with F11, which will launch the EXE and stop on the first line of user code. Both of these options are available on the context menu for the EXE project in Solution Explorer window as illustrated below:
If the EXE was built with SourceLink enabled then information about the source will be included in the PDBs and Visual Studio will try to download the source automatically. This is a really good reason to use SourceLink with your projects. Even if you have a local enlistment you might not have the same version that was used to build the binary. SourceLink is your sure-fire way to make sure that the right source is linked with the right binary.
You can also use the profiling tools with the EXE by launching them from the Debug -> Performance Profiling. From the launch page of the profiling tools you can select what tools to use against the EXE. More information on profiling can be found in the docs over at : -us/visualstudio/profiling/profiling-feature-tour?view=vs-2019.
Have you heard of dnSpy? It does not need the source code but decompiles the binary directly into C# code. Also no pdbs necessary. Much better than Visual Studio. But the best of all is that it pretty much looks like Visual Studio just with a better feature set. And it is open source. See -net-4-8-can-break-your-application/ for more information. You can even patch mscorlib if you want to.
We have observed that cortex XDR always blocks the code written in microsoft visual studio. General codes in C language like Hello world and addtion of two numbers is also geeting blocked in local analysis and it takes a lot of time to get verdict from wildfire to allow it. Usually whenever developer is running in debug mode this issue is faced and in debug they need to frequently change codes and debug it. When i discussed with one of palo alto support techinicial he suggested to whitelist the workspace folders or add signature and allow it which is not feasible solution as workspace paths keep changing per systems and users. Similar issue we observred for python codes also and after wildfire check that code shows as malware (false positive as many time when we report it as incorrect verdict gets changed).
Is there anyone who also faces same issue and found solution on this please help on this.
Thanks in advance.
Cortex XDR
I've checked above documents/article for exception profile and signer exception. But unfortunetly it didnt worked in my organization. As developer are creating exe by compiling the codes and running those directly, so signatures they are not addin g there and not required in there projects. For local analysis exception as checked visual code application is running/compiling that codes and geneating exe with powershell.exe process and creating exception for powershell.exe is not recommended in our org as it might lead to any other threat execution.
Very strange behaviour of XDR i observed when 1 developer was compiling and running code through visual code application. same code was generating diff hash valued exe every time so xdr was taking long time for analysis and it was in evaluation status for every time. So there are such case where user is frequenlty creating and running exe's and it not feasible every time to ask wildfire to recheck verdicts.
3a8082e126