Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 14 years ago.
Improve this question
This is not a newbie question:
My desktop computer that is running Windows Vista tends to freeze on occasions. Freezes last around 5-20 seconds after then, the systems goes back to normal like nothing happened. This happens fairly often (I can safely expect this to happen within 30 minutes). During the freeze, I can move the mouse cursor, however switching to the different application does not work. Key presses and mouse clicks are buffered, and are applied once the system unfreezes. I believe this is incompatibility with a driver, but would be interesting to know.
So my question is: How would one debug such scenario? Considering I can not isolate a process to take a memory dump of, or even if I could try to dump Explorer, I can't control the process that would create the memory dump.
** Clarification **
I guess since the question is misunderstood, I'll clarify; I am not concerned with fixing the system, I am interested in how to debug system code. How would you debug system resources? Is there any way to do something like adplus -crash on a system process to create a dump on an exception (if one does happen but is swallowed). Or is there a way start a debugger during bootup to make sure that it allows for monitoring of drivers as well. I am sure that this is done by driver developers on regular basis, so looking for some information.
Timur
This lack of responsiveness doesn't sound like a true freeze since you apparently don't have to reboot afterward. It might just happen because one or another applications has taken up 100% of cpu for a time, preventing all activity on the system. If you run Windows Task Manager or Process Explorer, you might be able to see that one or another apps has to 100% cup for a time. Process Explorer is nice because it shows more services as well as applications.
First place to start is with the system event log. See if it's disk non-responsiveness issue or if there is something else going on.
Take out everything that's not necessary (sound card, network card, connected printers, cameras, etc.).
Run for a while and if the problem doesn't occur, it was one of those devices, or a conflict between them.
If it still happens, go further; remove the mouse and keyboard and use remote desktop to control the computer, or try replacing your graphics card with another.
While it won't help Windows users, I'd like to mention the Linux Magic SysRq feature which can help at times like these.
A number of the Sysinternals utilities such as Process Explorer and Process Monitor might help to isolate what is causing the problem.
However, if you really want to debug the problem, look no further than Debugging Tools for Windows, and WinDbg in particular.
Related
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 7 years ago.
Improve this question
Project Description
I wrote a plug-in for a CAD system that batch translates CAD files. I want to be able to run the plug-in unattended. While processing the CAD files, user interaction is sometimes requested from the CAD program itself. Another guy I am working with on this project wrote a program using AutoIt to respond to the message boxes, and this is working for a majority of the situations encountered.
The plug-in is written in C++ using Visual Studio 2010, and the script program using AutoIt. The operating system is Windows 7.
Problem
Some CAD files will cause the CAD program to lock up. We attempted to overcome this by using the AutoIt program to check for "Not Responding" in the window title, then kill and restart the CAD program and plug-in and pick up where it left off. This works for files that are actually locking up the CAD program. The problem is that the "Not Responding" sometimes appears in the window title when the CAD program is just taking a long time to complete, and not actually locked up.
Current Work-around
The work-around we have come up with right now is to set a delay in the AutoIt program after the "Not Responding" appears, then check again before restarting the program. The problem is that it is just guess work on how long to set the timer.
Question
Now for my question. Is there a Windows API I can use to distinguish between when a program is actually locked up or just taking a long time? Or do I just have to live with setting the timer high enough where I think it will be enough to cover this situation?
Unfortunately becoming unresponsive is neither a necessary nor sufficient condition to consider a process locked-up. A good programmer could easily keep the UI responsive, while the algorithm thread has descended into an infinite loop.
Things to try:
Start creating a log of CAD file size shown again time it took to complete the conversion. This will quickly allow you to estimate the wait time for a given input size. In case this is correlated. This way you do not have to wait for ages if the CAD program locks up frequently on small input.
Observe the behavior of the CAD program, when it is locked up. Is it spinning the CPU (infinite loop) or dead-locked at a low CPU utilization (probably mutexes waiting for each other)? How about during a successful conversion? Is the CPU always maxed out or going up and down because interleaved IO happens? If you find a pattern of differences, then this might help you to distinguish still running from dead-locked.
Send failing CAD files to your CAD vendor and let them fix their code (haha, I know).
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 10 years ago.
Improve this question
I have a bunch of Windows 32-bit fullscreen EXEs that were compiled for the Windows XP era and use some version of DirectX for settings the graphics mode: 320x240x8. It is hardcoded, native (not faked in any way), and the binaries cannot be touched, recompiled or modified in any way (don't ask).
I'm trying to get these to run on Windows 7 and later (it doesn't even run on XP without the right card and driver, just to clear up any confusion). They only run if the video card and its driver specifically supports this mode, which is extremely rare, regardless of whether it's run on XP or 7.
I have been on this problem for a long time, asking experts for help numerous times and getting all kinds of potential solution, which I've tried one by one. Each of them fail with the same error: can't set video mode. The problem is always that it cannot set the video mode. The obvious solution is that it cannot attempt to set the video mode, because it is not supported. So I need some kind of small EXE that I can bundle with these EXEs and which can be set up to "wrap around" it and fool it into thinking that it's actually set the mode, whereas it's actually running in some kind of emulated video window.
I have tried "Wine on Windows", various utilities that "change the resolution", running it inside a VM, compatibility settings, etc. Just about anything you immediately think of. Nothing works at all. But the VM thing wouldn't be good even if it did work, because this has to be "distributable" as well.
Can anyone help me? Is this even possible to solve at all? It seems so bizarre that it's not possible to "trick" the programs into thinking that they actually did get to set the video mode.
I hope that a true expert will be able to come up with some solution.
My driver experience is not in video, but I reckon you should be able to write a driver that responds to/intercepts directx calls with what you want it say. As I understand it the video stack doesn't have the filter drivers though.
However, that emulated mode will need to support an awful lot of the direct ex API I suspect. Unless of course the number of calls is very low.
Display Driver Model (XDDM) Design Guide should be your starting point.
You may want to give this a try: http://www.makeuseof.com/tag/2-ways-force-directx-applications-launch-windowed-fullscreen-windows/
Summary
DXWIN -- Forces DirectX programs to run in a window.
D3DWindower -- Very similar program. English port of Japanese program.
I've used DXWIN in the past to keep programs out of full screen modes my hardware didn't handle well. On the downside, you get a small window.
Edit: Neither program mentions running in Windows 7, and of course there is no mention of 64 bit OSes. If either one works, post an solution and I'll upvote you for it.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 5 years ago.
Improve this question
If possible, describe platforms/languages/symbolic formats supported and if full support is provided (historical states back) or partially (only code can rerun with no rescue for states).
Further information about performance or resources needed is welcome but optional.
The new IntelliTrace historical debugger feature in Visual Studio 2010 seems to fit what you're asking for. See Debugging With IntelliTrace:
Debugging with IntelliTrace, available
in Microsoft Visual Studio 2010
Ultimate, provides an enhanced picture
of your application compared with
traditional debuggers. Traditional
debuggers show you the state of your
application at the current time with
limited information about events that
occurred in the past. You must either
infer events that occurred in the
past, based on the state of your
application at the current time, or
restart the application to re-create
past events. With IntelliTrace, you
can actually see events that occurred
in the past and the context in which
they occurred. This reduces the number
of restarts that are required to debug
your application and the possibility
that an error will fail to reproduce
when you rerun the application.
GDB does, with reverse execution and checkpoint/restart.
Green Hills Time machine Debugger
Chronon for java supports full stepping back and seeing entire state info at any point in time.
PythonTutor (http://pythontutor.com/) Lets you do this for small code examples in several programming languages.
Dr. Scheme, also known as PLT Scheme, will let you step backwards and forwards in a Scheme program. Full support for maintaining the state, as far as I can tell, though I haven't used it much. Runs on Windows, Mac and Linux.
I have never used a debugger with the ability to step backward. I just did a Google search and didn't find much...
I did find this:
http://video.google.com/videoplay?docid=3897010229726822034
Searching for "Bill Lewis debugger" led me to:
http://undo-software.com/undodb_about.html
The ability to step backward implies preserving a lot of state: if you change a variable in one line of code, and then you want to step backward, presumably the variable should revert to its previous value. If you change a register, it should revert to its previous value, and that includes the flags register. If you allocated memory, presumably it should be de-allocated. And so on. It's a big job in general. It looks like this debugger is using copy-on-write technology to actually do all this. I guess if a virtual machine like VirtualBox is possible, so is this.
This is still not a mainstream feature. One feature I have commonly seen is the ability to "set the next line". Say you call a function and it returns a value that surprises you; you set the "next line" to the line before the function, and then single-step into the function. Microsoft Visual Studio debugger can do this and so can gdb (the jump command). This ability is of limited use if the function corrupted the stack. Then, you really need to start over!
Computers have gotten so fast, it's much less painful to start over from the beginning than it used to be. You can just set a breakpoint before the point where you want to go back, and re-run the program from the beginning.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 3 years ago.
Improve this question
As a programmer I found it very hard to use my laptop and workstation with two different input devices, Can anyone suggest a good solution to use single mouse and keyboard to control my two machines
I am not looking for a Virtual Machine or RDP solution to see my machines in a single monitor,
Synergy.
Synergy lets you easily share a single mouse and keyboard between
multiple computers with different
operating systems, each with its own
display, without special hardware.
It's intended for users with multiple
computers on their desk since each
system uses its own monitor(s).
Redirecting the mouse and keyboard is
as simple as moving the mouse off the
edge of your screen. Synergy also
merges the clipboards of all the
systems into one, allowing
cut-and-paste between systems.
Furthermore, it synchronizes screen
savers so they all start and stop
together and, if screen locking is
enabled, only one screen requires a
password to unlock them all.
P. S.
See also how to fix Synergy problems on Vista.
What you want is a small gadget called a KVM switch (keyboard, video and mouse switch). Googling for that term will hook you up with plenty of suppliers.
There is also a neat software solution called Synergy that lets you use your cursor and keyboard input over multiple computers connected by a network.
Yet another vote for Synergy for a software KVM solution. I'm not sure about the others, but it's unique if your computers are running different operating systems. It worked very well when I had a W2k/Linux setup across 3 computers.
Synergy is great, but also give something like VNC a try: it consolidates not only the keyboard and mouse but also the screen. In my case my desktop monitor is much larger than my laptops, and I'm more comfortable facing forward anyway (not looking off to the side where the laptop is.)
There is a lag compared to using a KVM switch, but no loss in video quality.
In my experience Synergy is the best way to merge multiple monitors.
Others include:
- x2vnc
- x2x
- win2vnc
- osx2x
- win2x
... pretty much just take what OS/platform you're on, which one you want to connect to, and put a '2' in the middle. Type that into google and you're good2go.
For my linux machine I use QuickSynergy since it provides a gui for easier configuration. It also has a Mac OS version.
The best...
Synergy
I'll put in another vote for Synergy, but with a caveat - setup can be a little tricky. The first time I tried it, I could move my cursor over to another PC but I couldn't move it back. Spend some time with the documentation before you proceed.
InputDirector is better than Synergy. Here's why...
It has built-in AES encryption functionality (without requiring you to install OpenSSH) for secure transfer of input between machines.
It allows cut & paste of text and files between machines (by automatically translating to C$ and D$ shares)
Based on extensive use with a laptop, it is far more reliable and stable than Synergy when reconnecting after undocking & docking. Synergy would frequently just stop working after docking and undocking, requiring me to kill it, restart it, and reconnect. InputDirector rarely has any issues.
The configuration UI is easier to use, and has more options, than Synergy.
Lots of little things, like matching of cursor location between machines during screen-edge transitions, and overriding mouse settings of "Slave" machines with those of the "Master" machine.
Beyond that, as far as I can tell, it does everything Synergy does. There's only a Windows version, but apparently it's also Vista compliant as well.
I've used both tools extensively, first Synergy, and then InputDirector. InputDirector is just a more robust application. It has all the features of Synergy and then some, plus the key ones listed above. It's website isn't as attractive, and while it isn't GNU GPL'd like Synergy, it free nonetheless, and an oustandingly well-functioning tool.
I used to use a KVM switch, but lately I've started running all my computers as virtual machines on a single hardware platform. Each "system" is a window on my desktop!
I have a triple monitor display, and I just remote desktop into my other machines. I have 2-3 laptops on my desk at any given time, and 3 servers to administer. Over a 1 gbps connection, I have very little latency to worry about, and I can be working on three computers at once without much trouble. This may or may not help you, but I thought I would throw it in there for you.
If you mean: two machines on your desktop, a lot of places use KVM-style switches.
They come in legacy PC-style and also USB. The USB version works with Macs and PCs.
My experience is that the small desktop switches are a bargain, and if you learn the keyboard shortcuts, you'll jump back and forth without much problem.
The machine room, 3-level tree KVM's are also pretty useful. They flake out more often, but when you have 60 machines, you simply can't have 60 pairs on input devices.
I'll second Zarkonnens comment about KVM Switches as I use one for this purpose all the time. However I might share some rather frustrating experiences with them:
I have found that PS/2 interfaces tend to be somewhat more reliable on KVM switches than USB - I have had very bad experiences with some supposedly upmarket DVI-USB KVM kit from Gefen and Avocent. Due to a quirk of my Viewsonic monitor where it would drop back to analog most of the time these were exacerbated to the point of the system being nearly unusable.
DVI and USB are finicky. DVI monitors will often time out and sleep if they get no signal. The KVM switch will assume that there is no monitor if it is not active, which will then be passed back to the video card. USB interfaces will also get put to sleep randomly.
The net effect of this was that it was very difficult to get two machines to boot up and work on the KVM switch and the switch would lose keyboard or mouse input on one or both machines every few days. This was followed by an hour or more of trying to get all of the hardware to come up and play nicely. I got the same issue with the Avocent and Gefen switches on several different machines.
My older Belkin VGA/PS2 kit worked fine with the Viewsonic monitors on VGA but I spent nearly £1000 on switches and cabling to try and get a working DVI-USB KVM setup.
In the end I got two HP LP2065 screens that didn't have the bug that the Viewsonics exhibited. These have two DVI inputs and I used one of my older Belkin PS/2 switches to switch the keyboard and mouse. The computers are plugged directly into the monitor and the monitor's input selector is used to pick the computer. The keyboard and mouse are switched off the KVM switch. This is the setup that I'm using today.
The monitors and KVM have to be switched individually but it's much more reliable than the DVI-USB KVM switches that really did not work at all. Caveat emptor.
You should also check out Multiplicity from Stardock.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 4 years ago.
Improve this question
We are currently working on a new version of our main application. one thing that I really wish to work on is providing support for multiple monitors. Increasingly, our target users are adding second screens to their desktops and I think our product could leverage this extra space to improve user performance.
Our application is a financial package that supports leasing and fleet companies - a very specialised market. That being said, I am sure that many people with multiple monitors have a favourite bit of software that they think would be improved if it supported those extra screens better.
I'm looking for some opinions on those niggles that you have with current software, and how you think they could be improved to support multi-monitor setups. My aim is to then review these and decide how I can implement them and, hopefully, provide an even better environment for my users.
Your help is appreciated.
Thankyou.
Few random tips:
If multiple windows can be open at one time, allow users to have them on separate screens. Seems obvious, but some very popular apps (e.g. Visual Studio) fail miserably at this.
Remember the position of the last opened window, and open new windows on the same screen as before. However, sometimes users switch between multiple and single-display (e.g. docking a laptop with an external CRT), so watch cover this case as well.
Consider how your particular users work, and how having two maximized windows simultaneously might help. Often, there is a (fairly passive) window for reference (e.g. a web browser/help) and an active window for data entry (e.g. editor/database) that users switch between.
Do not put toolboxes/toolbars on a different window than objects they operate on (it's inconvenient to move the mouse so far).
Apple's Human Interface Guidelines for the Mac have covered window management on multiple displays since 1987, when the Mac II was introduced with six slots that could all contain a graphics card. The guidelines offer a few good guidelines that you might not think of at first when implementing multiple window support. For example, if a window spans multiple displays, which display should new windows be opened on? There's an answer around Figure 14-33 in the chapter dealing with Window behavior.
Microsoft may have something similar now for Windows developers to follow; if that's the case, check it out and follow their guidelines since you don't want to behave differently than the other apps on the system (or that your users are used to) for no good reason. However, if there are no guidelines, follow Apple's as they're fairly well thought-through and were originally developed through experimentation and research.
Please Please Please. If you remember window positions for multiple monitors. Please detect if the second monitor is connected. I have a laptop that is sometimes docked. It is very annoying when I try to open a window and it opens off screen.
It's annoying when I drag a window to another monitor, and then if the application generates a popup dialog, or spawns another window, if that popup/dialog gets displayed back on the primary monitor.
I haven't developed for multi-monitors, but I think this can be better handled if you position child windows/dialogs centered on their parent window, rather than on the desktop center (which I'm guessing is what happens in the case I describe above).
I'm going to have to a give a nod in dbkk's direction as they captured a couple of the major points that you need to remember.
Also, I would suggestion paying attention to how you use dual monitors and try to keep that in mind as you are developing. Generally you should try to avoid doing the things that applications you work do that annoy you. Also, don't assume that just because the user has dual monitors that they are going to want to work with your application on dual monitors.
The biggest thing that I would stress is keeping track of where the focus is in the application and making sure that any pop-ups occur within that region, one of the things that people seem to dislike the most is having a window pop-up in a different window then the one they are working on.
Definitely keep dialogs near where you clicked to bring them up. Remember what monitor the window is on between sessions. Be aware that if they have less monitors than the last time your app was run that you need to bring the windows back to a visible area. Provide an icon or button to switch monitors. Depending on the type of app it may be useful to be able to easily tile your app's windows on a monitor or on all.
One thing to keep in mind is that the user may have more than two monitors. My main system has six monitors, and I've run 4+ monitors on Linux, Windows, and Mac OS. Many applications--even multi-monitor utilities--will support 2 monitors but freak out over more than 2.
Applications work best when they know about where their windows are and relate to the locations of those windows. And as someone else mentioned, if you're going to remember where a window was, make sure that geometry still makes sense when the user comes back.
If the OS/window system dispatches an event related to the change of screen geometry, handle it if you're doing anything funky.
I think most applications that are well coded generally work these days.