43

I have had reports of my remote workstation freezing for several months, and it turns out that this is happening:

  1. User goes to print something to PDF (or save it).
  2. The file dialog box comes up asking where they want the file to go.
  3. They click something else, or the dialog otherwise somehow ends up behind something.
  4. They sit and stare at the PDF software that won't do anything, because it's waiting for them.
  5. They decide the "computer" is "frozen" and call in to have it restarted, which my other (Non IT) staff just does.
  6. They complain to me that the computer is slow and keeps freezing.

This seems to be happening a lot. We are a bookkeeping company and do a lot of printing / PDF work.

I've tried the human approach, which would be educating the users. No luck. I don't think they are going to get it.

How can we fix this? Is there a way to make Windows (or Acrobat, if you know anything about that - it's my very favorite program) just put the file somewhere by default to prevent the user from having to deal with the file dialog?

This is a Windows 7 x64 computer, accessed remotely via Remote Desktop Connection.

Eli
  • 741
  • 2
  • 8
  • 16
  • I _think_ PDFCreator let's you set a default output dir. You gotta test it though. – pauska Jan 17 '14 at 00:26
  • 22
    Layer 8 problem/wetware fault. If education fails, only recourse is to hit users with LART until problem recurrence ceases. – HopelessN00b Jan 17 '14 at 00:34
  • LART? I'm not familiar with that term. What does it mean? – Nzall Jan 17 '14 at 12:52
  • 5
    @NateKerkhofs: LART = Luser Attitude Readjustment Tool. See e.g. http://www.catb.org/jargon/html/L/LART.html – sleske Jan 17 '14 at 13:21
  • 5
    [Kids can not use computers](http://coding2learn.org/blog/2013/07/29/kids-cant-use-computers/) – VL-80 Jan 17 '14 at 15:44
  • Can you blame them for thinking that? – MDMoore313 Jan 17 '14 at 16:34
  • I call these pop-unders, they are like pop-ups, but they hide them self under there main window. I get them a lot when using MS-Windows, much less when using KDE on Debian Gnu/Linux. My solution is: I try not to use MS-Windows where ever possible, and never give it to beginners, nieve users or anyone that may call be for support. – ctrl-alt-delor Jan 17 '14 at 17:54
  • 1
    @HenkLangeveld, This is name of the article. That phrase in my comment is a link to resource where you can read it. Indeed it contains data on what can be done about it. – VL-80 Jan 17 '14 at 18:18
  • @Nikolay comment withdrawn - my question was a mistaken attempt to invite people to discuss. It feels inappropriate now. – Henk Langeveld Jan 17 '14 at 21:48
  • @richard Sounds like a perfect way to limit your userbase! Thanks for the suggestion! – PeeHaa Jan 18 '14 at 00:56
  • @richard The OS and or desktop environment choice has nothing to do with it, it is possible to implement popups properly (and also in an incorrect manner like in OP's case) on both windows and many of the gui toolkits for gnu/linux, acrobat just seems to be badly designed in this respect. I would suggest the OP looks for another PDF software, and doesn't change his entire companies OS. – w4etwetewtwet Jan 19 '14 at 12:41
  • 1
    @handuel and yet Windows7 clearly fails badly, across nearly all apps, including Explorer windows, to keep popups either in front or accessible from the taskbar. "Get a Mac" is scarily appropriate here. – Carl Witthoft Jan 19 '14 at 17:26
  • @CarlWitthoft I haven't used windows for a while, however my memory is that if you tried to interact with a window that had a currently open dialog, the dialog would flash at you, and make a noise, and you would be unable to click within the window. – w4etwetewtwet Jan 19 '14 at 20:38
  • @handuel sadly, no. No such luck – Carl Witthoft Jan 19 '14 at 21:45
  • 3
    @handuel I said **mostly** caused by the **windowing system**, not always caused by he operating system. Also If the question was about a bad application on KDE, then I could tell you how to fix it, by changing the policy of how KDE manages that application. On windows the policies are fixed and the application is in charge (not the windowing system). – ctrl-alt-delor Jan 20 '14 at 09:23
  • @richard Ah, Ok, sorry for the misunderstanding. – w4etwetewtwet Jan 20 '14 at 17:15

9 Answers9

79

They decide the "computer" is "frozen" and call in to have it restarted, which my other staff just does.

Here is your problem. This is not a technical fault, so don't try and implement a technical solution.

Instead, you should implement a process whereby every call or ticket for this type of problem actually gets troubleshooted before any action is taken. People tend to stop making silly mistakes when you make them fix it themselves.

If a user calls in with this problem - just ask them if they have any open dialogue windows, or if they have tried pressing ALT+TAB.

Make a wiki item on your help page with some simple troubleshooting steps that the user can take. That way when they call in with this problem, you can ask if they've checked the "My computer is frozen" troubleshooting guide.

HopelessN00b
  • 53,385
  • 32
  • 133
  • 208
blacklight
  • 1,369
  • 1
  • 10
  • 19
  • 28
    +1 for recognizing that technical solutions solve technical problems, not people ones. – HopelessN00b Jan 17 '14 at 00:35
  • 20
    A wiki page with troubleshooting steps? Isn't that where they store the Coca Cola recipe to be sure no one will ever find it? – Marcks Thomas Jan 17 '14 at 15:17
  • 2
    +1 My experience supporting quirky software is that one-the-spot-here's-how-to-get-yourself-out-of-this-jam training really helps them and you. – poke Jan 17 '14 at 18:15
  • 7
    Every time the IT staff reboot a computer, they teach the users “your computer was broken, a restart was necessary, there was no other option”. – ctrl-alt-delor Jan 18 '14 at 14:03
  • 2
    While the rebooting part is a people problem, I would definitely call it a technical problem that a modal dialog end up *under* the main window. This is a bug that should be reported to the vendor of the PDF printing software. I for one would be very annoyed with such a bug. – nitro2k01 Jan 18 '14 at 16:50
  • @blacklight, unfortunately the original problem is technical. Granted tech support should "know better" but the support person can't easily distinguish this over the phone. Have you answered a call from a frustrated user while you are being monitored for how many minutes you are on each call? This problem has to be resolved at its root not by education or workarounds. I've suggested a solution below that's extremely simple and would eliminate calls for support. Also when their computer is frozen, how are they going to get to the guide called "My computer is frozen"? – LMSingh Jan 24 '14 at 21:51
42

Your problem is step 5, where your other staff restarts the computer without doing even the most basic troubleshooting.

I assume you're referring to IT staff, who should frankly know better, and not make the problem worse, which is what they do when they just reboot the computer without doing even basic troubleshooting. Rectify this problem first, and the user problem will get better.

Your staff needs to show the users why this is happening, while this is happening if there's any hope of having it stick. Not unlike housebreaking a puppy: If you smack it on the nose when it urinates on your carpet, it will learn not to urinate on your carpet. If you wait until 10 minutes after the fact, it won't know why it's being punished, and will never learn. Users, much like puppies, need this immediacy if there's any hope of having them learn anything, and that's why telling them what the problem was after the computer's been bounced isn't working.

Of course, you'll still have infuriatingly dense users who just don't (or won't) get it, but that's out of your control, and frankly a management problem. My advice on that situation is (assuming you are a manager) to talk the managers of your worst offending users, and point out how much productivity (in their department, as well as yours) is being wasted because their users not checking for a simple save dialogue.
By pointing out how their employees refusal or inability to learn simple tasks is hurting them and their departments, those managers will be much more open to solving the problem with the tools at their disposal. When presented with the problem this way I've seen managers in other departments take it on themselves to "train"/"educate" their users on this type of simple thing, and even discipline or terminate employees who just wouldn't or couldn't get it. (As in: "Sorry that you forget your password every 3 hours and can't log in, but it means you're not a productive employee, and we can't afford to employ you anymore. Get out.")

And on a personal note let me tell you: it's quite satisfying to hear a sales manager scream "It's not IT's fault you're too stupid to click a a button!!!"

voretaq7
  • 79,345
  • 17
  • 128
  • 213
HopelessN00b
  • 53,385
  • 32
  • 133
  • 208
  • 6
    "Sorry that you forget your password every 3 hours..." -- Best argument for at-will employment I've ever heard. – Brian S Jan 17 '14 at 17:15
  • everyone does this, "I don't know what to do, I will call someone who does." we don't try to figure it out first, we don't have time for that, we don't have time to do a quick search on google about the issue we have, what we may have done to cause it. – Malachi Jan 17 '14 at 21:26
  • 3
    @Malachi: Yes. But most people will learn to fix _often recurring_ problem themselves if the knowledgeable person tells them how, because they don't have to wait for somebody each time. – Jan Hudec Jan 18 '14 at 11:06
  • Hey, No, they are unfortunately accounting staff who just walk over and hit the power button =o) I could wish I had more IT staff around here... – Eli Jan 23 '14 at 10:10
35

This is sometimes due to a design limitation in x64 Windows with regards to interaction between 32-bit applications and 64-bit drivers. In addition to print dialogs, another common scenario where this occurs is when using 32-bit Internet Explorer and dialogs for smart cards.

Microsoft provides some background information on the cause here:

The Save As dialog box appears behind a 32-bit application when you print to an XPS Document Writer printer on a 64-bit version of Windows 7
http://support.microsoft.com/kb/2567869

Printer drivers are implemented as dynamic-link libraries (DLL) that are loaded into a process that is printing. Printer drivers are implemented as 64-bit DLLs on 64-bit versions of Windows. Printer drivers are implemented as 32-bit DLLs on 32-bit versions of Windows.

A 32-bit process cannot load 64-bit DLLs. Therefore, 64-bit versions of Windows support printing from 32-bit processes through the Splwow64.exe process. Splwow64.exe is a 64-bit process that can load 64-bit printer drivers and handles printing on behalf of 32-bit processes.

When an application calls the StartDoc function to print to the XPS Document Writer printer, the XPS Document Writer printer driver displays a Save As dialog box so that users can specify the name and location of the XPS file. The owner window of the dialog box is typically the active window of the thread that is calling the StartDoc function, and the dialog box will appear over the active window.

When a 32-bit application calls the StartDoc function on a 64-bit version of Windows, the Splwow64.exe process calls in to the XPS Document Writer printer driver on behalf of the 32-bit application. In this scenario, the Save As dialog box is unowned because the thread in the Splwow64.exe process does not have an active window. Additionally, the dialog box may appear behind the application that is printing because the Splwow64.exe process does not have permission to set the foreground window.

The StartDoc call does not return until the dialog box is dismissed, so the application may seem to stop responding.

The Save As dialog box has its own button in the Windows Explorer taskbar if it is created by the Splwow64.exe process. This is because the dialog box is unowned. The taskbar button also flashes when the Splwow64.exe process cannot set the foreground window.

Greg Askew
  • 34,339
  • 3
  • 52
  • 81
  • 1
    It is interesting to know WHY ms-windows sucks, but what can we do about it. Other than install Linux. – ctrl-alt-delor Jan 18 '14 at 13:57
  • Is there an option to, at least, make the task bar entry flash for new windows, until the user interacts with them. – ctrl-alt-delor Jan 18 '14 at 13:59
  • 2
    @richard: I once developed an application that periodically checked for dialogs that had certain text in the title bar, and bring them to the front. I will check around and see if I can find it. I originally created it Outlook reminder dialogs that were occluded, but it can be configured for anything. – Greg Askew Jan 18 '14 at 22:43
  • @GregAskew, that is the working solution for this Problem, it is rather easy using AutoHotKey or similar – Sebastian Godelet Jan 19 '14 at 15:34
  • @richard to say that issues like this are limited to Windows is a bit... blind? Windows definitely has problems, but Linux as a work/play environment leaves a lot MORE to be desired. – WernerCD Jan 19 '14 at 21:33
  • @WernerCD Sorry if I gave that impression. I can't remember who said it but this quote comes to mind “Unix [and there for Linux] in an outdated (1960's system), it is unreliable, hates its users and bad in every way. Unfortunately it is the best and most modern system we have.” – ctrl-alt-delor Jan 20 '14 at 09:29
10

Even when you've encountered this problem before, it can be a real PITA to go hunt for a hidden modal dialog box.

Ultimately, it's a UI problem shared between platform and application. If users get confused by my product, it's a bug in the product. The application could show an indicator in the main window saying [pending print dialog (Click here to Cancel)]. But this is not an option for the system administrator.

For windows, the [Windows]-M shortcut may help (show/hide desktop), but that's still part of user education, and Helpdesk training.

Henk Langeveld
  • 1,294
  • 10
  • 25
  • open up a task manager and see what doesn't belong. – Malachi Jan 17 '14 at 21:27
  • @Malachi - the task manager won't help in locating the modal dialog box, as it is part of another valid application. – Henk Langeveld Jan 17 '14 at 21:40
  • not always, if there is an error box that "pops under" you will see that. and if you know the window you were in you select it in the task manager and then "switch to" – Malachi Jan 17 '14 at 23:06
  • 3
    Technically, [Windows]-M is "Minimize All". [Windows]-D is "Show Desktop". Of course, they typically serve a similar function (except in this case, from my experience. – Joe Jan 18 '14 at 17:41
  • 1
    "If users get confused by my product, it's a bug in the product." I couldn't say it better. And I sure tried! ;) – I'm with Monica Jan 20 '14 at 14:16
7

Configure an auto-pdf printer?

Not sure if this might be an option worth looking into, but I wanted something vaguely similar: Auto PDF printing without prompts or popups.

I have a program that prints stuff that I'm upgrading and for testing purposes I want to print to PDF, auto-name it and not have to think about that part of the process.

I setup Pdf24 on my computer. When I print to that printer, through the setup, it automatically prints to a folder. Options include auto-open folder, auto-open file, auto-name with parts like date-time stamp, etc.

You can even customize the look of the program with company logo which is unique.

(I'm not affiliated in any way with Pdf24 other than it meeting my recent needs)

WernerCD
  • 344
  • 2
  • 6
  • 18
6

This is a UI/Windows design problem. Hitting the users over the heads is unfair to them.

Since it's happening enough times, you might consider an automation solution.

Use something like autohotkey to put a macro in their autostart.

The macro periodically checks for a windows type (i.e. save as dialog specific to PDF printer) and issues a "bring to front" call to it.

LMSingh
  • 160
  • 4
  • 1
    While I agree with the general sentiment (a lousy product should be called out, and this is certainly lousy UI/UX design!) when you inform the users of the cause of the problem and they still insist on behaving like brain-damaged howler monkeys on a cocaine-fueled bender (power-cycling machines for no valid reason) you've got a serious Layer 8 (user) problem that needs to be addressed. – voretaq7 Feb 04 '14 at 22:28
  • @voretaq7 LOL on brain-damaged howler monkeys... IAC, I did address the problem in my answer. So many well meaning forums are simply using this as a soap box opportunity. Folks don't we all have better things to do. Like I said, write a 10 line macro, debug it and get on with it. Takes a lot less time than the soap box podium. Adobe can't/won't fix the problem because it's a Windows 32 / 64 design problem. The new MS CEO will take your call in year 2098 AD. DUH! Greg Askew's answer above explains the details if you care. – LMSingh Feb 05 '14 at 09:13
2

You might get some mileage out of a product I used to use (before I had the opportunity and good sense to stop developing in a Windows environment.) It was called "Push the Freakin' Button" and it was a rock-solid bit of freeware.

I just looked and it seems to still be available here.

It will still take a little ingenuity to solve your problem, but I know that tool was a god-send for me when we had remote servers using a 3Com driver that occasionally assumed a user was present. Nothing like a System-modal error dialog to put a quick stop to file sharing on the network.

After I discovered it, there was no end to the uses I had for automating all those little, annoying, 'are you sure' dialogs, of which Windows developers are apparently so fond.

Anyway, I hope this helps!

MrWonderful
  • 121
  • 2
1

This may, or may not be, all the fault of the users.

I've found that for some strange reason certain programs in Win 7 x64 amazingly enough sometimes load the dialog window onto the screen UNDER other windows, and not on top as modal. It is somewhat madding. One if these that I use that does this is what prints pdf documents.

But having said that I agree with the other A above that this is a training issue.

--

However, I can imagine a looping script in PowerShell which gets run as a background job, which regularly checks for certain tasks on certain workstations, and for how long they have been active and possibly idle, and kills any such process. But it's not a very good solution I don't think, because it might break other things. :-( You know what is said about Engineers, that they don't solve problems but rather trade one problem for another.

Elliptical view
  • 684
  • 6
  • 9
1

It's true there is little you can do when it comes to people not having the sense to look for a save button. Especially when it is a simple task they have done repeatedly in the past and should already know what do to based on past experiences.

But perhaps I can offer some advice that might help. I have seen a similar problem in the past whereby a dialog box was hidden under other windows. I believe in order to fix the issue I updated the video drivers and rebooted the PC, afterwards the dialog box opened on top of the windows like it was supposed to. If you can get the dialog box to show up on top of the other windows, your end user might clue in, the next step they need to do is, "save"

Another option is to update or change your print to PDF software. I use a free software call Foxit PDF, I will paste a link below. I hope this helps you in your quest. Although I do agree, you also need to train your tech support staff to train the end user how to perform the simple tasks, like looking for a save button for example. Once the end users are better trained, they will become more productive and less of a drain on your department. Good Luck

Foxit PDF software

Frank R
  • 141
  • 3