So when a program dies rather ungracefully, modern versions of Windows put up a dialog that reads:
Windows is searching for a solution to the problem
It clocks for a little while, then doesn't find anything. Well, I've never had it tell me it's found a solution.
The question is, what exactly is going on when this dialog is being shown? What are possible things it can show as "solutions"? Is there a way my application can tap into it?
Obviously, if I know enough about what could go wrong, I should handle it in the app, so I'm left wondering what this actually does.
Anyone know?
Windows Error Reporting is capturing a stack trace of the failed program and sending it off to Microsoft. The data it collects is stuffed into an enormous database for vendors to research; if this is your program, you can sign up here. If the vendor submits a patch, Windows will notify you.
You can tap into it, either by customizing the info, triggering reports for (soon to be) fatal errors, and much more.
Related
Foreword
Since this appears to be a bug in the d3d9 Emulation on the Windows side, this would probably best addressed to Microsoft. If you know where I could get into contact with the DirectX Team, please tell me.
For the time being, I'm assuming that the only real chance we have is working around the bug.
What
We're investigating an inresponsiveness found in the Game Test Drive Unlimited 2.
Only when opening the Map and only when having an "RTX" Card (I think the most precise we got is GDDR6, because AMD also seems affected).
After long debugging, we found out, that it's not a simple fault of the game, but instead Present returning D3DERR_DEVICELOST even when having the game in Windowed Mode.
When the Game is in Fullscreen Mode, it properly does the required roundtrip over TestCooperativeLevel and Reset, but after the next frame is rendered, Present has lost the device again, causing the Hangup.
Now I'm looking for pointers on how to solve this issue. While it's probably some internal state corruption of some sorts, it's definitely triggered by an API Call only present when rendering the Map in that Game.
We will try to dig into d3d9.dll, but my suspicion is that the error code just comes from some Kernel/Driver Call, where our knowledge and tooling ends.
Ideally I'd like to fuzzy-find the drawcall by just hooking everything and omitting random apicalls, but I guess it's just not so easy and causes a lot more errors in most conditions.
Also note that an APITrace we did, showed D3D_OK for every single call including EndScene, up until Present, so it's not as simple as checking the return codes.
Trying to use Direct X 9 in Debug/Diagnostic Mode is also not really possible on Windows 10 anymore apparently, even when installing the SDK from June 2010
Thanks in Advance for any idea and maybe addresses to direct this problem to.
I'm developing with Qt. Following a tiny change my program now will not start up and if I run the debugger, this dialog box is displayed:
I have looked at several other answers to questions about this error and Qt, and they all propose using a different compiler or a different version. I don't believe this will solve my problem.
Searching a little more diligently on Google, I came upon this article, about Visual C++ which suggests, very plausibly, that additional information is available but has been swallowed by one of the tools somewhere. The article goes on to suggest that by changing something in the registry, you can get additional information output when the error occurs. Now, I can run my program from the command line, with minimal intervening tools, so this looked like a really useful idea. Sadly, the link in the article that I believe will tell me more about the required registry change is dead.
Does this ring any bells with anyone? How can I found out the dll and entry point that isn't being found?
Thanks to helpful comments, I managed to get the additional trace enabled using the "image files" tab of gflags.exe. I then found an enormous quantity of trace information on the "Debugger Log" tab of the QCreator debugger.
Close examination showed that the function containing the tiny chnge which kicked off this problem was failing to load.
I have no idea what caused this, but a clean rebuild of the program in question now allows it to run to the point of the original failure that made me want to make a tiny change in the first place.
I guess the moral of the story is to do a clean build immediately when things start getting weird - before trying to pin down the weirdness!
M 8.0.1, windows 7.
A debugging question.
Sometimes when I start M and open my notebook (which has dynamics enabled in it before I closed it) I get this message
The problem is, no matter if I click on wait, or disable dynamics, the message keeps coming back.
I have to terminate the process itself (i.e. Mathematica) from windows task manager to get out of this.
Clearly I seem to have a bug somewhere in dynamics in my code.
My question is: Is there a way for M to tell me which dynamic objects is causing this problem? And any idea why telling it to disable dynamics updating is not helping here (as I keep getting the message).
thanks
You may have some luck by evaluating:
SetOptions[$FrontEnd, PrintKernelDynamicTraffic -> True]
This will cause the Mathematica FrontEnd to print messages to the system console (on Mac, I don't know where it goes on Windows) whenever it sends Dynamic evaluations to the kernel. If you can find the last Dynamic evaluation to print out when the message appears, that should be the one which is taking a long time to evaluate.
You'll probably want to disable this when you're done debugging so it doesn't fill your system log with millions of debug messages.
You may find DebugTrace, written by David Bailey, useful. It is a debugger which may also be used to debug dynamic constructions. In this documentation there is an example on how to debug such programs. Basically you set a breakpoint in your code, run it, and after it's done you are presented with detailed information on what happened when.
In general I highly recommend giving it a try, not only for the dynamic functionality.
I am working on building a system that can monitor how users react to security alerts on their systems (software updates, warnings etc.). It also needs to monitor the web traffic and the processes running on the system and I am looking to the community to help me design this system. We intend to provide users with test laptops and monitor their behavior over a period of time to see how they react to security alerts thrown by various applications and the OS(windows in this case).
Following are my questions
Can I use windows hooks to solve the first problem i.e finding how users reacted to the alerts thrown by various applications. Specifically, can global hooks be used to solve this?
(How this information should be collected (XML?) and relayed back to a server(how frequently?) is another problem)
Can I do this in C# or it has to be done only in c++ or VB?
Do you know any alternate approach to solve the problem? Is there any software that has these capabilities.
I have many more questions but getting these answered would be a good first step. Really hoping for some good insights from the knowledgeable people on this community
Thank you in advance
Edit:
Example scenario is when adobe prompts you to update the flash player or the antivirus prompts you to update definitions or any application displays a notification(security related having keywords like update, warning, install etc.) needing the user to take some action. Windows system updates is another example. I want to know how the user reacted to these alerts/notifications/updates (which are typically a pop-up window). So i was wondering if i placed a global hook that can monitor the content of the windows displayed on screen and notify me(server) when certain words like update, alert, warning etc. appear in the content/title of the windows and what the user did with the message(dismissed it, Oked it etc). Unfortunately, i do not have any more specifications than this. I can use anything I want to achieve this and I am not clear on what my choices are.
Edit 2:
After having reviewed my requirements and having read about hooks, I feel like I could achieve this by a combination of hooks and the following textGrab SDK, http://www.renovation-software.com/en/text-grab-sdk/textgrab-sdk.html. I want some guidance to know if I am on the right track. I am thinking if I can install hooks then it gives me handles to all possible windows on the screen and I can use the textGRAB SDK to look for certain keywords in those windows. Although this may capture some interesting text, I am still not sure how I will know what action the user had taken on the window. Anybody having any experience with either hooks or textGRAB, please let me know if this looks like a reasonable thing to do. If the community has some other Ideas on how I could possibly monitor security related messages thrown by any application in the system, please suggest. I am looking forward to some useful advice for completing a challenging project.
First of all, you need to define, how you will "see" security alerts in code. "Security alert" is quite a vague term. Will it be some window with some caption and some message to the user or ... ?
Next, about web and processes: Windows hooks won't help you with your task. They are more low-level and not as advanced as you'd need. You can't hook network traffic (you need either network filter driver for pre-Vista or Microsoft Filtering Platform for Vista and later). See this question for some information about checking the process list with C# (there seems to be no easy way to catch process startup either).
It honestly sounds like you need a more solid direction. I commend you for trying to provide details, but It appears that you still need more information about your problem(s)..
I will attempt to answer some of your questions, but like I said - it sounds like you need to know more about your problems before we can provide you with optimal answer(s).
-Alerts is too vague a term, you will need to define this better. Are these 'alerts' applications that YOU have control over or are they third party applications? Not every application will show an 'Alert' in the same fashion, and even if they did - I think using a System Level Hook would probably be too problematic to implement your solution with. I'm not saying it's necessarily impossible, but you're talking about possibly implementing a different set of logic(to determine the data for a given application's Alert(s)) for each application that you want to monitor.
-It's impossible for any of us to determine the optimal storage mechanism for your particular needs, that is something that you will either need to provide more details about or decide on your own.
-How often you collect data is also something that you will have to either provide more details for or decide for on your own.
-C/C++ Would probably provide you with the most portable solution, although there is nothing preventing you from using c# to call Win32 API. (Not everyone has the .NET framework installed - believe it or not)
-The problem that you mentioned appears to be a somewhat specialized problem... I don't know of any existing software that will do everything that you want to do.
Another possible issue that you haven't touched on:
You haven't specified your target audience for this 'service', but I want you to know that if I found an application monitoring as many events as what you're talking about doing, I would promptly remove it and write a nasty letter to the company that wrote it.
In summary, Read this Article on hooks to get a better understanding of how they work.
I am trying to help a client with a problem, but I am running out of ideas. They have a custom, written in house application that runs on a schedule, but it crashes. I don't know how long it has been like this, so I don't think I can trace the crashes back to any particular software updates. The most unfortunate part is there is no longer any source code for the VB6 DLL which contains the meat of the logic.
This VB6 DLL is kicked off by 2-3 function calls from a VB Script. Obviously, I can modify the VB Script to add error logging, but I'm not having much luck getting quality information to pinpoint the source of the crash. I have put logging messages on either side of all of the function calls and determined which of the calls is causing the crash. However, nothing is ever returned in the err object because the call is crashing wscript.exe.
I'm not sure if there is anything else I can do. Any ideas?
Edit: The main reason I care, even though I don't have the source code is that there may be some external factor causing the crash (insufficient credentials, locked file, etc). I have checked the log file that is created in drwtsn32.log as a result of wscript.exe crashing, and the only information I get is an "Access Violation".
I first tend to think this is something to do with security permissions, but couldn't this also be a memory access violation?
You may consider using one of the Sysinternals tools if you truly think this is a problem with the environment such as file permissions. I once used Filemon to figure out all the files my application was touching and discovered a problem that way.
You may also want to do a quick sanity check with Dependency Walker to make sure you are actually loading the DLL files you think you are. I have seen the wrong version of the C runtime being loaded and causing a mysterious crash.
Depending on the scope of the application, your client might want to consider a rewrite. Without source code, they will eventually be forced to do so anyway when something else changes.
It's always possible to use a debugger - either directly on the PC that's running the crashing app or on a memory dump - to determine what's happening to a greater or lesser extent. In this case, where the code is VB6, that may not be very helpful because you'll only get useful information at the Win32 level.
Ultimately, if you don't have the source code then will finding out where the bug is really help? You won't be able to fix it anyway unless you can avoid that code path for ever in the calling script.
You could use the debugging tools for windows. Which might help you pinpoint the error, but without the source to fix it, won't do you much good.
A lazier way would be to call the dll from code (not a script) so you can at least see what is causing the issue and inspect the err object. You still won't be able to fix it, unless the problem is that it is being called incorrectly.
The guy of Coding The Wheel has a pretty interesting series about building an online poker bot which is full of serious technical info, a lot of which is concerned with how to get into existing applications and mess with them, which is, in some way, what you want to do.
Specifically, he has an article on using WinDbg to get at important info, one on how to bend function calls to your own code and one on injecting DLLs in other processes. These techniques might help to find and maybe work around or fix the crash, although I guess it's still a tough call.
There are a couple of tools that may be helpful. First, you can use dependency walker to do a runtime profile of your app:
http://www.dependencywalker.com/
There is a profile menu and you probably want to make sure that the follow child processes option is checked. This will do two things. First, it will allow you to see all of the lib versions that get pulled in. This can be helpful for some problems. Second, the runtime profile uses the debug memory manager when it runs the child processes. So, you will be able to see if buffers are getting overrun and a little bit of information about that.
Another useful tool is process monitor from Mark Russinovich:
http://technet.microsoft.com/en-us/sysinternals/bb896645.aspx
This tool will report all file, registry and thread operations. This will help you determine if any you are bumping into file or registry credential issues.
Process explorer gives you a lot of the same information:
http://technet.microsoft.com/en-us/sysinternals/bb896653.aspx
This is also a Russinovich tool. I find that it is a bit easier to look at some data through this tool.
Finally, using debugging tools for windows or dev studio can give you some insight into where the errors are occurring.
Access violation is almost always a memory error - all the more likely in this case because its random crashing (permissions would likely be more obviously reproducible). In the case of a dll it could be either
There's an error in the code in the dll itself - this could be something like a memory allocation error or even a simple loop boundary condition error.
There's an error when the dll tries to link out to another dll on the system. This will generally be caused by a mismatch between dll versions on the machine.
Your first step should be to try and get a reproducible crash condition. If you don't have a set of circumstances that will crash the system then you cannot know when you have fixed it.
I would then install the system on a clean machine and attempt to reproduce the error on that. Run a monitor and check precisely what other files (dlls etc) are open when the program crashes. I have seen code that crashes on a hyperthreaded Pentium but not on an earlier one - so restoring an old machine as a testbed may be a good option to cover that one. Varying the amount of ram in the machine is also worthwhile.
Hopefully these steps might give you a clue. Hopefully it will be an environment problem and so can be avoided by using the right version of windows, dlls etc. However if you're still stuck with the crash at this point with no good clues then your options are either to rewrite or attempt to hunt down the problem further by debugging the dll at assembler lever or dissassembling it. If you are not familiar with assembly code then both of these are long-shots and it's difficult to see what you will gain - and either option is likely to be a massive time-sink. Myself I have in the past, when faced with a particularly low-level high intensity problem like this advertised on one of the 'coder for hire' websites and looked for someone with specialist knowledge. Again you will need a reproducible error to be able to do this.
In the long run a dll without source code will have to be replaced. Paying a specialist with assembly skills to analyse the functions and provide you with flowcharts may well be worthwhile considering. It is good business practice to do this sooner in a controlled manner than later - like after the machine it is running on has crashed and that version of windows is no longer easily available.
You may want to try using Resource Hacker you may have luck de-compiling the in house application. it may not give you the full source code but at least maybe some more info about what the app is doing, which also may help you determine your culrpit.
Add the maximum possible RAM to the machine
This simple and cheap hack has work for me in the past. Of course YMMV.
Reverse engineering is one possibility, although a tough one.
In theory you can decompile and even debug/trace a compiled VB6 application - this is the easy part, modifying it without source, in all but the most simple cases, is the hard part.
Free compilers/decompilers:
VB decompilers
VB debuggers
Rewrite would be, in most cases, a more successful and faster way to solve the problem.