Something has changed recently on my machine such that I now see lots of .NET JIT-V messages in my Output window while debugging a .NET application. Here's a sample of the sort of output it now shows which I'd like to suppress.
JIT-V : Initialize Thread: 7880 : Non-Virtualized
JIT-V : Initialize Thread: 21936 : Non-Virtualized
JIT-V : Initialize Thread: 6080 : Non-Virtualized
JIT-V : Initialize Thread: 9860 : Non-Virtualized
JIT-V : Enabling Virtualization on ThreadId 23320
JIT-V : Disabling Virtualization on ThreadId 23320
JIT-V : Initialize Thread: 13136 : Non-Virtualized
Does anyone know where the switch to disable these sorts of messages is? FWIW, I am using Visual Studio 2015 with Update 1. Moving to Update 2 or 3 is not an option right now but I suspect that shouldn't be necessary as these are relatively new messages.
I have googled and searched SO for these messages (and parts of these messages) with no useful hits.
My suspicion is that perhaps Debug tools for Windows or some other utility has enabled a regkey or other .NET system-level setting.
These are definitely not printed from our application code.
open procexp
find process: SearchIndexer.exe
right click it and suspend it and its child processes
enjoy!
Related
I have successfully used the solution for detecting opening windows described here: UIAutomation FlaUI - Detect opening windows on application level.
However, I would also like to also detect closing window events in addition to opening window events.
I duplicated the code in order to detect the second event:
AutomationElement root = automation.GetDesktop();
UIA3AutomationEventHandler automationOpenEventHandler = new UIA3AutomationEventHandler(
root.FrameworkAutomationElement,
automation.EventLibrary.Window.WindowOpenedEvent,
HandleOpenEvents);
automation.NativeAutomation.AddAutomationEventHandler(
automation.EventLibrary.Window.WindowOpenedEvent.Id,
root.ToNative(),
(Interop.UIAutomationClient.TreeScope)TreeScope.Descendants,
null,
automationOpenEventHandler);
UIA3AutomationEventHandler automationCloseEventHandler = new UIA3AutomationEventHandler(
root.FrameworkAutomationElement,
automation.EventLibrary.Window.WindowClosedEvent,
HandleCloseEvents);
automation.NativeAutomation.AddAutomationEventHandler(
automation.EventLibrary.Window.WindowClosedEvent.Id,
root.ToNative(),
(Interop.UIAutomationClient.TreeScope)TreeScope.Descendants,
null,
automationCloseEventHandler);
However, only one of the two (I believe the second one declared above) actually works.
Note that if I declare just one of the handlers above, either the open or close, it works fine. I just don't know how to get both going.
Any help would be appreciated!
I'm working on a C# project with WPF in Visual Studio. My application was building and running perfectly yesterday. As far as I know, I haven't made any changes to the build process.
Today, when I try to run a Debug build, it builds and deploys correctly, and a process starts, but the application startup window never displays (not even in the Windows Taskbar). I tried to attach the Visual Studio Debugger to the process as recommended in this (external) link, but the process is grayed out in the Visual Studio > Debug > Attach to Process... popup. It does not display even if I browse to the Debug folder and double-click the *.exe file.
The unusual thing about this is that if I run in Release rather than Debug, everything works fine. I've checked the Project > Properties > Debug configurations; Debug and Release are identical (I just used the defaults when I created the project). Other projects also work fine in both Debug and Release build. I tried comparing the *.csproj and *.sln files, but I couldn't find any significant differences.
I've tried searching for this, but it's really difficult to find anything useful. This question is unrelated, since the window does not even appear in the taskbar in my case. If I try to include the word "debug," I get a flood of questions about redirecting output to the console, which is not my problem.
I'm not sure what code/configurations are relevant to this question, so please let me know if you need more info about the setup.
Edit 1:
I tried putting a break in the InitializeComponent() method in the auto-generated part of my App class:
public partial class App : System.Windows.Application {
private bool _contentLoaded;
/// <summary>
/// InitializeComponent
/// </summary>
[System.Diagnostics.DebuggerNonUserCodeAttribute()]
[System.CodeDom.Compiler.GeneratedCodeAttribute("PresentationBuildTasks", "4.0.0.0")]
public void InitializeComponent() {
if (_contentLoaded) {
return;
}
_contentLoaded = true;
#line 5 "..\..\App.xaml"
this.StartupUri = new System.Uri("Views\\MainWindow.xaml", System.UriKind.Relative);
#line default
#line hidden
System.Uri resourceLocater = new System.Uri("/MyProject;component/app.xaml", System.UriKind.Relative);
#line 1 "..\..\App.xaml"
System.Windows.Application.LoadComponent(this, resourceLocater);
#line default
#line hidden
}
/// <summary>
/// Application Entry Point.
/// </summary>
[System.STAThreadAttribute()]
[System.Diagnostics.DebuggerNonUserCodeAttribute()]
[System.CodeDom.Compiler.GeneratedCodeAttribute("PresentationBuildTasks", "4.0.0.0")]
public static void Main() {
MyProject.App app = new MyProject.App();
app.InitializeComponent();
app.Run();
}
}
This will break for either Debug or Release if the code is between if(_contentLoaded) { and _contentLoaded = true; but everywhere else in the method, I get "The breakpoint will not currently be hit. No executable code of the debugger's target code type is associated with this line." I get the same message if I try to put a breakpoint anywhere in the Main() method.
Even though Debug breaks at the certain interval mentioned above, it still does not display if I continue.
Edit 2:
Things are starting to get weird. Since the project is backed up in Git, I rolled all the way back to the first commit and to several others along the way. I still couldn't get anything to display for Debug, but Release still worked fine. I even tried deleting the local repo and recloning it, but no success. The stranger part about this is that everything runs fine from the backup folder. Why does the folder name make a difference?
I never found out what caused the issue to occur in the first place, but I was eventually able to come up with two workable solutions.
As described in the edit: Copying the solution directory to another directory and running it from there works for some reason.
For some reason, running Debug|Any CPU didn't work, but running either Debug|x86 or Debug|x64 did.
It's unlikely that someone else will run into my exact situation, but I'm leaving my solutions here for posterity. Maybe someone else can benefit from this.
Issue:
I am trying to update the GUI from a second thread.
Unfortunately the label stays the same. At first I thought there is an issue with the dispatcher but it works fine. It appears that the configuration is not threadsafe!
Code to reproduce:
I have a Settings File which is mainly used to keep variables persistent during application relaunches:
this is the Update code:
// get the amount of tickets created for me last week
int amountOftickets = JiraInterface.DayStatisticsGenerator.GetLastWeeksTicketAmount();
config.Default.Lastweekstickets = amountOftickets; // int == 12;
// Update GUI on GUI thread
mainWindow.Dispatcher.Invoke(() =>
{
mainWindow.SetIconsAccordingtoConfig();
mainWindow.NumberTicketsCreated.Content = config.Default.Lastweekstickets.ToString(); // int == 0!!
});
Does anyone have an Idea on how to shove the running configuration from the thread who updated it to the Gui thread?
After a quick look in the documentation, it seems that you have 2 options:
You can either use the Dispatcher.Invoke to set your config.Default
on GUI thread.
It seems that .NET Core and .NET Framework support synchronized SettingsBase which is what the Configs are ( https://learn.microsoft.com/en-us/dotnet/api/system.configuration.settingsbase.synchronized?view=netcore-3.0 )
EDIT 1:
Looking into the C# Properties more, it seems that if you look in your config file in Visual Studio under:
Properties -> Config.settings -> Config.Designer.cs
During the class initialization it seems that .NET Framework, already uses Synhronized property which should make the config thread safe
private static Config defaultInstance = ((Config)(global::System.Configuration.ApplicationSettingsBase.Synchronized(new Config())));
It could be that when you created this file, Synchronized wasn't used, so your config file isn't thread safe, especially if it was created in code and not designer/properties
From Microsoft Docs on SettingsBase Synchronized:
The indexer will get and set property data in a thread-safe manner if the IsSynchronized property is set to true. A SettingsBase instance by default is not thread-safe. However, you can call Synchronized passing in a SettingsBase instance to make the SettingsBase indexer operate in a thread-safe manner.
I am trying to use a Microsoft demo project which shows how to do ETW event tracing in WPF as a basis for some specific profiling I want to do in an app I'm developing.
Compiled as is, the demo works fine. However, change the target framework from .Net 3.5 to .Net 4, and it breaks. Clearly there is some significant change between the framework versions.
The question is what changed, and (more importantly) is it possible to fix the demo?
My investigation so far
Adding a Debug.WriteLine to FpsEventConsumer.EtwEventCallback I see that in framework 4 either no events arrive or two events arrive, both with Header.Guid of 68fdd900-4a3e-11d1-84f4-0000f80464e3; one with Header.Class.Type of UCE_GLASS_START and the other with UCE_GLYPHRUN_START. Note that I also observe these events, among many others, when testing under framework 3.5.
By digging around in referencesource.microsoft.com I discovered that MS.Utility.EventTrace's static field EventProvider of type MS.Utility.TraceProvider controls what gets sent to ETW. Using reflection to access the event provider (since it's non-public) I observe that in 3.5 it starts with everything enabled (_enabled is true, _flags is 2147483647, _level is 5); and in 4 it starts with everything disabled (_enabled is false, _keywords is 0, and _level is 0). But changing those values with reflection doesn't seem to help the situation much. At best, on a very rare occasion I get a few events emitted before the UCE_ ones mentioned above.
By placing a WriteLine in TraceConsumer.ProcessTrace as follows, I observe that the p/invoked call continues to block, so the problem isn't that the trace is being interrupted.
ErrorCode errorCode = UnsafeEventTrace.ProcessTrace(handleArray, handleArray.Length,
(FILETIME)startTime, (FILETIME)endTime);
+ System.Diagnostics.Debug.WriteLine("ProcessTrace: " + errorCode);
if (errorCode != ERROR.SUCCESS)
{
errorCode.OutputErrorMessage("TraceConsumer.ProcessTrace");
}
It turns out that the answer was there all along in one of the referencesource files I looked at:
/// ...
/// TreatAsSafe: it generates the GUID that is passed into the TraceProvider
/// WPF versions prior to 4.0 used provider guid: {a42c77db-874f-422e-9b44-6d89fe2bd3e5}
///</SecurityNote>
[SecurityCritical, SecurityTreatAsSafe]
static EventTrace()
{
Guid providerGuid = new Guid("E13B77A8-14B6-11DE-8069-001B212B5009");
...
The following simple patch to Sample.RunTrace causes events to start flowing (although they no longer include the particular event which the demo uses for the FPS).
- m_traceSession = TraceController.WpfController;
+ m_traceSession = typeof(System.Windows.Rect).Assembly.GetName().Version.Major == 3
+ ? TraceController.WpfController
+ : TraceController.GetController(new Guid("E13B77A8-14B6-11DE-8069-001B212B5009"), "WPF");
This is Windows Forms application.
As in title, I can't debug Task in Visual Studio 2015. If I will check breakpoint at line var a = costam(); it will be hit, but if then I will press step into, or continue, execution will not be continued. This works fine in Console Application. For now i checked, that error appears when I'am trying to run my own method in Task, or if I'am invoking something.
public partial class Form1 : Form
{
public Form1()
{
InitializeComponent();
Task.Run(() =>
{
var a = costam();
});
}
string costam()
{
return "s";
}
}
I would suggest changing the settings to break on any exception in the debug menu, not only uncaught ones. This option is called breaking when the exception is "thrown". Unfortunately the 2015 exceptions menu I'm not familiar with so I can't help you out with that.
There are certain exceptions that are caught and suppressed behind the scenes, especially with WinForms--constructors / load events are particularly shielded. It's likely that it doesn't like spawning a new thread in the UI thread which is why it's throwing an exception in your WinForms application but not the console application. This also explains why "stepping in" "doesn't work"--it steps in but the exception means the next breakpoint isn't hit.
Update 1 to VS2015 seems to solve this issue.