This is the day of weird behavior.
We have a Win32 project made with Delphi 2007, which hosts the .NET runtime and calls into .NET to show new forms, as part of a transition period.
Recently we've begun experiencing exceptions at seemingly random locations and points of our code: Arithmetic overflow or underflow.
The stack trace of one of these looks like this:
at System.Windows.Forms.UnsafeNativeMethods.DispatchMessageW(MSG& msg)
at System.Windows.Forms.Application.ComponentManager.System.Windows.Forms.UnsafeNativeMethods.IMsoComponentManager.FPushMessageLoop(Int32 dwComponentID, Int32 reason, Int32 pvLoopData)
at System.Windows.Forms.Application.ThreadContext.RunMessageLoopInner(Int32 reason, ApplicationContext context)
at System.Windows.Forms.Application.ThreadContext.RunMessageLoop(Int32 reason, ApplicationContext context)
at System.Windows.Forms.Application.RunDialog(Form form)
at System.Windows.Forms.Form.ShowDialog(IWin32Window owner)
at System.Windows.Forms.Form.ShowDialog()
at Gatsoft.Gat.UI.Windows.Forms.Remanaging.RemanageForm.DelphiOpenInNewMode(String employeeCode, String departmentCode, DateTime date) in C:\Dev\VS.NET\Gatsoft\Gatsoft.Gat.UI.Windows\Forms\Remanaging\RemanageForm.Delphi.cs:line 67
In the Visual Studio solution, one of the outmost class libraries (ie. pulls in all the references it can), has set a specific debug program, targetted for the Delphi project output. This allows us to debug .NET code from Visual Studio, even though the main bulk of the program is written in Delphi.
The problem only occurs when run from the debugger, not if we just run the exe file directly (either through explorer, shortcuts, or even Ctrl+F5 inside Visual Studio).
There's apparently no spyware on the machine (as hinted by this).
Any other things we can check?
Edit: It looks like the .NET debugger is enabling this SNaN flags, and the Delphi debugger does not. We'll have to investigate this further, but for now I'll accept #Lorenzo Boccaccia's answer.
Apparently Solved
Ok, it looks like we've finally nailed this problem. The problem started occuring without having the debugger attached as well, for our testers, so we had to prioritize the problem way up.
Finally we found one common issue with the machines that had the problem, they are Dell Lattitude D620 laptops with an NVIDIA Quadro NVS 110M, with an old driver from a system image used to provision the laptops, from back in 2006.
I found one post on the web, though I lost the url when I rebooted to update the display driver, that had a .NET service crashing, mostly when the machine was busy doing something on the screen. One way to reproduce his problem was to open a command prompt to C:\ and doing a DIR /S to just force a massive amount of screen updates, which would trigger the crash.
He too had a NVIDIA video card.
The problem on my machine occured roughly every 2-4 startups of our program, but after updating the video driver I've had 123 successfull startups without any problems. (BTW I can recommend AutoHotKey for such things).
So it looks like we've found the culprit, an old/buggy NVIDIA driver.
Updated this question so that perhaps someone in the future can save some time.
Now, if you'll excuse me, I'm going to go cry in a corner.
Jinxed!
I must've jinxed it. No sooner had I posted the above update than a colleague laptop failed, after updating the video driver.
Still, I'm positive it's a problem outside of our application now, so it just remains to figure out which specific things to update.
Further updates: Ok, my machine is now apparently fixed, not so with my colleagues machine. So far we've updated the BIOS, Chipset drivers, and currently SP3 for XP is on its way in.
A burn-in test will be done tonight, where the app will be left overnight starting up, as the problem cropped up either during startup, or at the first time some WinForms .NET code was executed. This app is mainly a Delphi Win32 app, but it hosts the .NET runtime, and the problem seems to be related to .NET code. When we "boot" the .NET runtime, the problem can appear, or when we fire the first .NET window from Win32 then it can also appear.
Statistically I'm ready to release this code now. Over the night the application has been started 3051 times without errors, whereas before I updated the video driver it crashed every 2-4 times.
Prodded and found(!/?)
This bug-fixing ordeal feels like going to the doctor, where the following conversation ensues:
Doc: Does this hurt?
Me: No...
Doc: What about now?
I've prodded and poked the application and finally I think I've found something we did that introduced this problem.
In our app we host the .NET runtime, from a Delphi 2007 Win32 application, and in our glue-code we have the following line (now):
rc := CorBindToRuntimeEx('v2.0.50727', 'wks',
STARTUP_LOADER_OPTIMIZATION_MULTI_DOMAIN or STARTUP_CONCURRENT_GC,
#clsid, #iid, UnkRuntimeEngine);
The two constants in the middle there was originally just a 0, meaning pick the defaults. This change was introduced a few months ago and the problem has been slowly creeping in on us after this. The change was introduced in order to encourage ANTS profiler to load our Win32 application + hosted .NET runtime in order to do performance profiling and the changes we introduced back then made that work. Additionally, the problem with arithmetic overflow/underflow has slowly been getting worse so I bet the problem didn't appear for a while after the change so it wasn't attributed to any of the changes we did.
Also, since we only (originally) saw the problem when running through the debugger, we thought something was wrong with Visual Studio and/or Delphi.
Anyway, statistically now, with a browser on one screen doing repeated scrolling up and down triggered by a javascript (apparently needed in order to trigger the bug), then I have been able to successfully start the application 726 times with a 0 in the call, and it crashes 5 out of 17 times with the two constants there.
Doc: Does this hurt?
And let's not get into who made that change in the first place. I'm sure the culprit wants to be left anonymous... cough
a debug version of a linked dll could be compiled with signaling nan support, see http://blogs.msdn.com/oldnewthing/archive/2008/07/02/8679191.aspx for an example of this problem.
that heisenbug was caused by uninitialized variables, here there could be a linked dll enabling the snan feature of the cpu and forgetting to disable it upon returning
Do the errors occur still occur if you attach the debugger after starting the application?
Related
I used to have the ability to inspect shaders in Visual Studio 2012, but now I've lost it. The UI doesn't actually crash, but the modeless popup message saying "This may take a few minutes" never bears fruit. I found a post at another site claiming that installing VS2012 Update 3 fixed the problem, but that hasn't helped in my case.
Back when using Pix was an option, I found that rendering outside of a BeginPaint() / EndPaint() pair for speed would cause debugging issues, but again that hasn't been the issue this time.
More info: There is a warning message initially, "Debugging information for 'YourApp.exe' cannot be found or does not match. No native symbols in symbol file". This is as I'd expect, as the main app is managed, with the DirectX work being handled via an unmanaged engine DLL that loads slightly later (once I know what bit version to use).
Tombola, I'm a developer on the Graphics Debugger in Visual Studio. As you've seen 2013 preview added some big stability and scaling improvements to the Graphics Debugger. What you were probably seeing before was a playback engine crash while attempting to start shader debugging. The Graphics Debugger tool shipped with some stability issues in VS 2012, but since then Update 2 and now VS2013 (RTM should also improve quite a bit over preview) have helped this issues greatly.
Have you tried debugging the first draw call in the frame?
The further down the frame, the more DirectX calls that are made before the shader executes, the longer the debugger takes to start; it can take a really long time for a complex scene.
If even the first draw call fails to start debugging, perhaps try commenting out code to reduce the number of API calls and see if there is a particular operation which causes the problem.
It turns out that VS2013 preview can debug all the shaders in VS2012 .vsglog files without difficulty (nb. express build lacks auto and watch windows for shaders). This requires Windows 8.1 preview of course. Setting these two up inside a dedicated virtual machine for safety costs about 8 gig (32 bit, VirtualBox).
I am experiencing the exact same issue as this fellow, and cant seem to find any real solutions to the issue. The only solution I've been able to find so far that works it not maximizing VS. Keeping VS in windowed mode fixes the problem completely, but as soon as it returns to maximized state UI elements no longer redraw unless the stale area is put under new active focus. This makes it impossible to develop and I'm forced to return to windowed mode. I've tried disabling hardware acceleration with no luck. Any Ideas?
There are a handful of feedback reports at connect.microsoft.com that describe a similar problem. But none that ever evolved to a solution, most typically the programmer that filed the report stopped responding when asked to provide additional diagnostics.
Clearly this is an environmental problem, something is wrong with your machine. VS2012 uses WPF for rendering, it puts non-trivial demands on the machine. You do need a solid video driver and a functional DirectX stack to make it work without problems. This tends to be an issue in general, video drivers are by far the most problematic kind of driver. Problems are roughly correlated with the age of the machine and how old the operating system is.
So a good starting point is to look for a video driver update first, visit the web site of the company that made your adapter to look for the latest. Reinstall DirectX on the machine next. If you were considering a clean update of your machine before, like updating the Windows version, now would be a good time to start with a clean slate.
We have a legacy VB6 app, which is critical to our business. We're working on re-writing it in .NET, but that's going to take a long time.
Over the last few years, this old VB6 app has had problems with third party controls that we purchased about 10 years ago, when we wrote the VB6 app. These problems are getting progressively worse. For example, the application will suddenly crash. When it does I'll check the user's event log to see what happened, and almost all cases one of the third party controls failed, and took the application down with it. Sometimes this causes the user to lose data.
We've done the best we can to mitigate this and that's helped tremendously, but haven't been able to prevent all cases of these failures. A few years ago, when this problem first started to show itself, I did some investigation into why these crashes were occurring and I remember some people saying that some of these problems were due to the service pack we had our application at. Our VB6 app is currently at service pack 5. I learned that Microsoft had come out with service pack 6, for VB6, and asked about that, back then, and people advised me to not upgrade to SP6 for VB6 due to incompatibility issues with our third party controls, so we've left things alone.
However, now these crashes are occurring more frequently. It's occurred to us that perhaps the issue is some recent updates to Windows may have already moved VB6 to SP6. Or, perhaps the advice I was given years ago about leaving our application at SP5 for VB6 was wrong. In any case, we need to find out if we can move our application to SP6 for VB6, and thereby hopefully reduce, if not eliminate, the number of fatal crashes these old third party controls are giving us.
Here's the list of third party controls that our application is currently using. Does anyone know if these controls will work with VB6 SP6?
Crystal ActiveX Report Viewer Library 11.5
Crystal Reports ActiveX Designer Design and Runtime Library 11.5
Crystal Reports ActiveX Designer Run Time Library 11.5
WSpell Spelling Checker Control version 1.0
Sheridan Data Widgets 3.0 A (in particular their Data
Grid, Data Combo and Data DropDown controls. It is these controls
which are at the root of all of our app's fatal crashes.)
I've used WSpell with VB6 SP6. Crystal was always pretty tightly in bed with Microsoft so I would expect that those work. Sheridan, well, I can't help you there.
That said... why ask? Just test it. You can always roll back if it doesn't work, right?
I can't give any advice about the Sheridan controls but we are using Crystal ActiveX Report Viewer and Runtime Library 10.0 with our VB6 app (using SP6) and this has no crashing issues.
We have multiple VB6 apps using Sheridan Data Widgets 3.1, mainly the grid but the dropdown a bit these days too. Everything ran fine on Vista and 7 but once a few people upgraded to 10 (we ignored/avoided 8) problems emerged quickly.
Loading the grid started making the app crash, but it was strange. I could call the load function (it populated the grid) when initially displaying information, and it was fine. Other functions would change the data and reload the grid, and most worked except for one. Nothing special or different about it, but the grid took a special dislike to it. What was annoying was if I threw in a MsgBox every time before a line was added to the grid (we use AddItem mode) the silly thing didn't crash.
Had a similar problem once with the grids, found I had to divert focus to a new form that appears for less than a second. Might be something to do with how the grid draws? Or judging by the function that causes it to crash when no others do, perhaps certain sequences of events cause the crashes.
Looking at the event log on Win10 it's telling me the faulting module name is USER32.dll, exception code alternates between 0xc0000005 and 0xc000041d.
I have a WinForms application that uses XNA to animate 3D models in a control. The app have been doing just fine for months but recently I've started to experience periodic pauses in the animation. Setting out to investigate what is going on I have established these facts:
It happens on my machine only, other machines works fine
Removing everything from my render loop does not improve the problem
In 2. I didn't actually remove everything, I limited my loop to set the viewport on my GraphicsDevice and then do a GraphicsDevice.Present.
Trying to dig further I fired up PIX to capture some statistics. Screenshots of two PIX runs can be viewed here (Run6) and here (Run14). Run6 is using my original render loop and Run14 is using the bare-bones Present loop.
PIX tells me that the GPU is periodically doing something, and I assume this is causing the pauses. What could be the cause of this? Or how do I go about finding out what the GPU is actually doing?
Update: since I usually trust my code to be perfect (who's laughing?) I started a new XNA project from scratch to see if it exhibit the same behavior. So starting a new XNA 3.1 Windows Game project and running PIX I get this timeline. The same periodic pauses. So the problem must be lower in the stack, in XNA or Direct3D.
So PIX shows that the GPU is working on something, I can see the list of DX calls made within each frame and the timing calculations shows that the pause occurs during (or after) the IDirect3DDevice9::Present call.
Update 2: I had previously installed and uninstalled XNA 4.0 CTP on the problematic machine. I cannot be certain that this is related but I thought that perhaps a reinstall of the XNA Game Studio 3.1 bits could make a difference. Turns out it did.
The underlying question remains the same (and the bounty is still up): what could affect XNA 3.1 (or DirectX) to make it behave like this and is there any logging/tracing power tool for the DirectX and/or GPU level out there that could shed some light on what is going on?
Note: I'm using XNA 3.1 on a Windows 7 x64 dual-core machine with 8GB RAM.
Note2: also posted this question on the XNA Creators forums here.
You could try to see if you can find something with Xperf that is close to your periodically problem, do not run your application but keep the programs open that would normally run besides your application. You could also try to do it again with the application running but it could give a cluttered view.
Start the tracing, do this in an elevated prompt.
xperf -on BASE+LATENCY -stackWalk Profile
Wait for a fair amount of time to be sure that the problem is traced.
Stop the tracing and open it like this.
xperf -d trace.etl
xperfview trace.etl
Analyze by looking at the graphs and consulting tables of specific intervals and see if you can find something that is related to the problem, the highest chance on finding it would be in the DPC and Interrupts section. But it might as well be something odd at the CPU or I/O section. Good luck!
Also more information on Xperf and how to obtain it, hopefully this delivers results.
If not, you can alternatively try GPUView which has been used for improvements in DWM,
this is also included next to Xperf with the Windows Performance Toolkit so you can easily try both!
log v
... wait for a fair amount of time to be sure that the problem is traced ...
log
gpuview merged.etl
In the case that gpuview gets out of memory you can try to add "/limit 3" or remove the v.
Read the documentation of the tools if you are stuck somewhere.
Hmm ... this seems to be occurring on the GPU, however it sounds like a CPU garbage collection issue. Can you run the CLR profiler and see if you can see any spikes in GC activity that you can correlate to the slowdowns?
I agree that it sounds unlikely since you can clearly see it in PIX, but it might offer a clue as to the cause.
If it's only happening on your own machine, then could it be drivers? Forgive me for being skeptical, but it's a 64 bit machine after all :D
This looks like either a vsync issue or GPU in its last throes. Since going back to a different version fixed it, and the "bottleneck" is in IDirect3DDevice9::Present lets go with the former option.
I'm not familiar with XNA so I don't know how much of the workings of D3D are exposed, but do you know what your PresentationParameters are set to?
Specifically try setting the swap effect set to Discard.
I saw that Beta 1 of VS2010 was publicly availible.
My question to those of you who has tried it is: does it work good?
Will it cause my computer to blow up in tiny pieces? Will it crash randomly? Will it work with some minor glitches? Or is it just perfect from bottom up?
I'm only coding school- and hobby-stuff, so nothing that someones life depend upon, but i still want software that works. How close to a final product is it? Is it worth trying?
It's a bit slow, and there's no offline MSDN, but it's worth trying IMO. Having said that it's slow, I still use it on my NC10 netbook, so it's clearly not that bad :)
I've got it side-by-side VS2008, and that hasn't caused any problems.
I've seen a couple of glitches (once the keyboard handling went completely wonky) but it's certainly usable. The main question is what you want to get out of trying it - in my case I absolutely need to code against C# 4 to explore the new features. I do most of that from the command line in fact, where the speed of VS obviously isn't an issue, but it's nice to see the VS-specific features as well (like the debug threading views for Parallel Extensions).
It seems more or less usable on the .NET side. The C++ side is a bit more sketchy. On one hand, they've added support for some very nice new C++0x features, on the other, they've broken some absolute fundamentals.
Your plain old main function won't compile in 32-bit with unicode enabled. (Workarounds: Either compile as 64-bit, disable unicode, or rename the function to wmain).
This seems to me to be a strong hint that the C++ side of things is nowhere near release-worthy. I'd probably wait for beta2 before doing any serious work with that.
I would say it is great, but the performance hurts a bit.
Here is an idea for you: Install it into a VirtualPC. Then you can play and not care what it does. You don't like it, delete the VPC image and keep on trucking. That is how I play with Microsoft betas now. I never install them on any real machine - too risky.
Usable: Yes.
Recommended: Not if you'r a touchpad-addict or dislike crashing apps.
I've been trying it for 2 weeks now coding small C#-projects and these are my impressions
Reasons to use 2010:
Looks good
Multi monitor support
I can see myself using the code templating but right now i couldnt find any really useful stuff except for reducing the fontsize of comments.
Zoom in the editor
Select a variable and then press shift+up/down to go to next usage of this variable
Ctrl+, brings up instant search of classes and functions in the entire project. (i've become really addicted to this)
Floating watches for single objects
Reasons to not use 2010:
TOUCHPAD SCROLL DOESN'T WORK IN THE EDITOR!!! (this is reason enough to not upgrade if you are using it on a laptop)
I've had some random app-crashes in the middle of just writing code, once or twice per day maybe.
UI sometimes freezes randomly for about 30seconds and then returns to normal.
It started to use 100% CPU power from one of my cores once when it was minimized in basic editing-mode and i was doing other stuff in other programs, i only noticed it because the fan started to go wild.
Otherwhise it's pretty similar to 2008. I haven't noticed any difference in speed like other people say.
You need to ask yourself: what is the advantage for you in using VS2010 over VS2008? I would suggest that there is no advantage if all you are doing is "school- and hobby-stuff".
I'm still using VS2008 for business related stuff (and, indeed, VC6 for some stuff). I prefer to wait until all the early adopters have tested it (and Microsoft has released at least one service pack after the real product release) before I do their testing for them.
It seems to co-exist with other versions of VS without causing any problems.
Regarding the slowness - it seems to be the UI that is slow, rather than building. Once it's going it doesn't seem much slower on my fast quadcore. I've yet to try it on my laptop.
It's usable enough, the small glitches that I've encounter weren't that bad. However, certain VS extensions(like XNA) don't work in VS2010 at the moment.
It's fun to toy with. Not usable for me, cause re#er does not support it yet (had to install TestDriven .NET which works through keyboard shortcuts only to run my tests).
Gave me an insight how addicted I am. :/
Btw, on Win7, without virtual pc it seemed even faster than vs2008 for me.
VS2010 doesn't yet support mobile device projects, which might or might not matter to you.
VC++ wise - VS2010 has a built-in 64-bit compiler, VS2008 does not.
You can supposedly add 64-bit support to VS2008, but it takes some effort.
I've been using VS 2010 beta (with .NET 4.0 beta) on Windows 7 RC. I've been trying to rewrite parts of a large-scale business application in it to see what can be done with it.
The UI freezes frequently. I'm talking 1-10 minutes between freezes. The UI does not come back, so I'm forced to kill devenv.exe every time it happens. Microsoft probably puts my error reports in their spam folder by now.
For me, VS 2010 beta 1 classifies as unusable. However, it's fast, the new IDE functions are very handy, and it's pretty. I keep coming back to it despite my resolutions to wait for a stable build.