|
Joking aside, I do run 8.1 too.
It isn't that bad, my only gripe is that it doesn't sleep by itself
|
|
|
|
|
S u n s h i n e wrote: Explorer leaks memory like a sieve.
Maybe on your machine but not on mine. Win7 x64 SP1.
Perhaps your machine has caught a nasty little virus?
|
|
|
|
|
No such luck, a virus would have been easier to get rid of. The thing is isolated from the outside world so that was unlikely in the first place.
|
|
|
|
|
Well, you've got something on that machine that is screwing with Explorer. It's not what happens to Explorer when installed "out of the box".
Do you have a crappy anti-virus installed? How about some integrated Zip utility? See the picture here?
In any case, if that's what you're seeing and you don't have any clue what's causing it, your best bet is to flatten the machine and rebuild. Install one thing at a time and test Explorer before installing the next.
|
|
|
|
|
Yawn.
Another user who blames Microsoft before even understanding what's happening. Bring back my jump-to-conclusions-map when you're done with it.
Bastard Programmer from Hell 
If you can't read my code, try converting it here[^]
|
|
|
|
|
It is most likely an Explorer Extension which is leaking.
Get the SysInternals autoruns utility and disable all but the extensions you trust.
|
|
|
|
|
Our support dept often gets very vague emails about 'something' being broken, without much details and we want to implement something to improve this and make it better / easier for developers to track down and fix issues.
Any suggestions for a system / procedure / form that can be used by users to report errors in software? Not so much a bugtracker, we have internal software for that, but something that can be used to help us get better and more complete issue reports from the users...
|
|
|
|
|
We use JIRA at the moment. Does the job.
|
|
|
|
|
Write your own.
Every bought in system I've worked with has been flawed, some seriously.
When you write your own you can force users or those answering the call to take the information you actually need. The users rarely tell you what you need to know unless someone draws it out of them. Too often those employed to take that info are crap at it.
Some men are born mediocre, some men achieve mediocrity, and some men have mediocrity thrust upon them.
|
|
|
|
|
Good idea. I guess a standard Issue / Error Report Form will be a good start.
|
|
|
|
|
I'm sorry but your post is too vague
Half serious 
You mean some kind of error reporting mechanism that you can build into an application?
|
|
|
|
|
Yup, something like that To get more info on the issue being reported.
|
|
|
|
|
Education.
No matter what you do in terms of procedures, users will spend as little time n it as they can - they are busy people who don't realise what you need to know. So teach them why you need to know, to try and encourage them to help you to help them!
Well, a man can dream, anyway... 
Those who fail to learn history are doomed to repeat it. --- George Santayana (December 16, 1863 – September 26, 1952)
Those who fail to clear history are doomed to explain it. --- OriginalGriff (February 24, 1959 – ∞)
|
|
|
|
|
Do you have a 1st line of support / customer service or helpdesk? Assign someone to that 1st line and train them to get all the information you need so they can pass it back to your developers. So tell them they need to look for a unique identifier, a page name, screenshots and get the error messages from the user.
Simon Lee Shugar (Software Developer)
www.simonshugar.co.uk
"If something goes by a false name, would it mean that thing is fake? False by nature?" By Gilbert Durandil
|
|
|
|
|
ask them to at least send a screen shot of the issue. this will help you to focus on particular module / screen.
Ravi Khoda
|
|
|
|
|
Create a error dump which will contain the Error Log and Stack Trace.Request users to send the error dump file.
___ ___ ___
|__ |_| |\ | | |_| \ /
__| | | | \| |__| | | /
|
|
|
|
|
Triage,
Employ someone cheap with little or no knowledge of the technology or the systems, to take the support calls/emails etc.
Never EVER let the users talk to anyone who knows anything about anything, unless they (the customer) are called directly.
Have the triage person trained to ask all the questions you know need asking and, if you don't get the information, go back to the triage person who then calls the customer and asks for the information.
The triage person can be on the customer's side "I know, I thought what you told me sounded fine, but for some reason they need to know if it was the iPad version or the PC version you were running"
Also Mr. triage can be pro-active - tell the customer they'll be called back within 2 hours, then calling them back, within 2 hours even if only to let them know there's no news.
internally you can continue to use the existing systems you do, safe in the knowledge that Mr. traige is getting all the information for you.
And Mr. triage is much cheaper than you.
|
|
|
|
|
Really? I thought we hated talking to customer support people who are clueless?
|
|
|
|
|
Yeah, we do, but what we hate even more is talking to users! 
Anything that is unrelated to elephants is irrelephant
Anonymous
-----
The problem with quotes on the internet is that you can never tell if they're genuine
Winston Churchill, 1944
-----
I'd just like a chance to prove that money can't make me happy.
Me, all the time
|
|
|
|
|
no, what we hate is talking to customer support people.
The idea of this role is that they aren't support - they are just a note-taker and question asker. they don't know how the system works, and their sole purpose is to collect data to pass on (if they're clever then they may also suggest an urgency status)
thing is, they're not some support twonk who think he knows everything and thinks you should be able to fix it if you just 'copy and paste teh bit that does it on this screen' - they're a cheap lackey who knows their place 
|
|
|
|
|
This is a great idea but you need to sack and replace them frequently. Even the simplest start to pick up knowledge after a while and then they start thinking for themselves which is never a good idea. Eventually they stop asking the questions and just forward things on because they have heard something similar before and know who to pass it to.
Some men are born mediocre, some men achieve mediocrity, and some men have mediocrity thrust upon them.
|
|
|
|
|
You're exactly right. backpackers make good ones.
|
|
|
|
|
There is no such system - it's a pure human factor. In or web application we have a build in reporting system, that takes the user by hand to do the best report immediately when error occurs - in most cases it does not help.
You have to educate your clients to that - there is no other way...
I'm not questioning your powers of observation; I'm merely remarking upon the paradox of asking a masked man who he is. (V)
|
|
|
|
|
Jacquers wrote: Our support dept often gets very vague emails about 'something' being broken, without much details and we want to implement something to improve this and make it better / easier for developers to track down and fix issues.
Hah! Don't waste your time making users fill something out. You'll get back a crap load of "default values" and/or textboxes filled with little to nothing at all.
The best information you're going to get is code sprinkled all over your application that tracks what was going on, a usually a simple kind of structure to track application state. When you get an exception that crashes your application, grab a copy of that "state structure" and include it in your own dump of the exception and state.
On top of that, you also force a crash dump of your application.
That's about the best your going to get, with no user interaction at all.
|
|
|
|
|
The best thing is to run an error logger with a built in "key logger" on your application.
There are few better feelings than being able to tell an obnoxious user that they lost their data because they pressed cancel instead of ok. 
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
