Topic Sponsor
2009 - 2014 Ford F150 General discussion on 2009 - 2014 Ford F150 truck.
Sponsored by:
Sponsored by:

Why Microsoft is Unreliable

Thread Tools
 
Search this Thread
 
Old 05-01-2013, 03:39 PM
  #11  
Senior Member
 
OddBall's Avatar
 
Join Date: Dec 2012
Location: Northern Va.
Posts: 341
Received 60 Likes on 50 Posts

Default

Originally Posted by Zixxer10r
That wasn't a system update, and SYNC doesn't randomly update by itself.

What you saw was the system message that pops up whenever SYNC is rebooted, for whatever reason. The major problem with SYNC (and it's been noted here a hundred times over) is that the processor that runs the whole OS is not fast enough to keep up with the demands of the different apps. When the system "hangs" there is background code that tells SYNC to reboot, and that is when you see the message that you did.

Just like any other computer, it's a good idea to reboot every so often just to clear cache and reset all your memory. THIS TOOL is what I keep on a USB thumb drive in my truck every day of the week, and any time I think about it, I'll plug in the stick until the message you saw pops up, then get out of my truck and go about my business. Once i've finished whatever it is I drove in my truck to go do, the system has rebooted and is running fresh again.

Here's the FORUM where I found the tool. Post #27 is where the good info starts.

I don't want to derail this thread too much but I have to take issue with one part though. People say that periodically rebooting a system is a good idea. It is not, with a qualifier: If you are experiencing a problem, yes, reboot for starters (non Unix platform) but otherwise rebooting is a bad idea. Just kill the offending process that's causing the performance bottleneck.

You're stressing the hardware by shutting down and re-initializing disk controllers, etc... If you're running a Windows system, of course rebooting makes sense on occasion as programs that are written poorly may consume too much RAM and/or not free the memory allocated to them upon exit. It's the universal cure-all for most MS related issues. But a blanket statement that rebooting periodically is a good idea needs to die already.


Most likely the reboots are caused by a fatal hardware error, like a double word offset memory or non-correctable memory error, bad RAM, etc... or even a known bug. The O/S has to panic and crash to maintain data integrity. Unfortunately you might need to take it to someone that can see if it logged any errors when it crashed.

Last edited by OddBall; 05-01-2013 at 03:54 PM.
Old 05-01-2013, 04:14 PM
  #12  
2013 King Ranch EB GemGrn
 
Zixxer10r's Avatar
 
Join Date: Dec 2012
Posts: 482
Received 80 Likes on 42 Posts
Default

Originally Posted by OddBall
I don't want to derail this thread too much but I have to take issue with one part though. People say that periodically rebooting a system is a good idea. It is not, with a qualifier: If you are experiencing a problem, yes, reboot for starters (non Unix platform) but otherwise rebooting is a bad idea. Just kill the offending process that's causing the performance bottleneck.

You're stressing the hardware by shutting down and re-initializing disk controllers, etc... If you're running a Windows system, of course rebooting makes sense on occasion as programs that are written poorly may consume too much RAM and/or not free the memory allocated to them upon exit. It's the universal cure-all for most MS related issues. But a blanket statement that rebooting periodically is a good idea needs to die already.


Most likely the reboots are caused by a fatal hardware error, like a double word offset memory or non-correctable memory error, bad RAM, etc... or even a known bug. The O/S has to panic and crash to maintain data integrity. Unfortunately you might need to take it to someone that can see if it logged any errors when it crashed.

There is no way to kill the offending process in MFT/SYNC, so your qualifier needs amending. I'm convinced that any errors a dealer might pull won't be able to solved by a software update of any sort. In this particular instance, the processor cannot keep up with the demands of the software and therefore "panics" in order to not have a total meltdown.

I don't restart my Mac just because, and there is a reason: it runs on Unix. MS products don't, and therefore the registry gets all jumbled around when opening and closing programs and other processes. MFT has the same base code for the OS, and therefore the "blanket" statement I applied is valid.
Old 05-01-2013, 06:55 PM
  #13  
Senior Member
 
OddBall's Avatar
 
Join Date: Dec 2012
Location: Northern Va.
Posts: 341
Received 60 Likes on 50 Posts

Default

Originally Posted by Zixxer10r
There is no way to kill the offending process in MFT/SYNC, so your qualifier needs amending. I'm convinced that any errors a dealer might pull won't be able to solved by a software update of any sort. In this particular instance, the processor cannot keep up with the demands of the software and therefore "panics" in order to not have a total meltdown.

I don't restart my Mac just because, and there is a reason: it runs on Unix. MS products don't, and therefore the registry gets all jumbled around when opening and closing programs and other processes. MFT has the same base code for the OS, and therefore the "blanket" statement I applied is valid.

You stated the following: "Just like any other computer, it's a good idea to reboot every so often just to clear cache and reset all your memory." This is factually and technically inaccurate. I have production MS boxes (more than 50) that have uptimes over 3 years and they run fine. They run CPU intensive applications 24x7x365. The only time they get rebooted is for patching or a hardware component has failed and that hasn't happened in 3 + years. For the record i've been responsible for tens of thousands of proprietary and open source *nix servers on all major commercial platforms.

So you're convinced the dealer won't be able to find anything? Good, maybe you should go work for Ford and tell them how to rebuild Sync. You're also stating the CPU can't keep up with the demands of the software. Validate that please, with actual evidence because I really would like to see that data. I also

The O/S these systems uses is stripped down and originally based upon Windows' old CE code with improvements but there would absolutely have to be a method to run it in debug mode or it writes to a system log file as they have to be able to diagnose problems properly.

Your experiences with MS notwithstanding are anecdotal at best. You haven't bothered to validate why -you- think a regular reboot is needed over the unsubstantiated claim the registry gets jumbled. I think thats a fair question to ask.

The latest Sync system uses a Freescale i.MX51 SOC ARM Cortex A8 CPU running at 600 mhz with 512 mb RAM and 2GB of NAND flash memory. If he's starving the CPU there IS another issue, a bug, a hardware failure and wholly unrelated to simply having CPU starvation. Why hasn't everyone else had issues doing very mundane tasks like using GPS and/or playing music?

I'm not trying to give you a hard time but I completely discount your analysis as you have no evidence to prove otherwise. This is what I do for a living and have done for more than 19 years now so I am speaking from experience.

Last edited by OddBall; 05-01-2013 at 06:57 PM.
Old 05-01-2013, 11:04 PM
  #14  
Senior Member
 
btexan's Avatar
 
Join Date: Jan 2012
Posts: 315
Received 79 Likes on 25 Posts
Default

Originally Posted by OddBall

You stated the following: "Just like any other computer, it's a good idea to reboot every so often just to clear cache and reset all your memory." This is factually and technically inaccurate. I have production MS boxes (more than 50) that have uptimes over 3 years and they run fine. They run CPU intensive applications 24x7x365. The only time they get rebooted is for patching or a hardware component has failed and that hasn't happened in 3 + years. For the record i've been responsible for tens of thousands of proprietary and open source *nix servers on all major commercial platforms.
.
In my 26 years of owning a system integration Var we can say the only OS that could run for years was Netware. 3 yrs uptime on a ms box yea right, considering most updates require a restart to apply.

The rest of your post may be accurate, but your first paragraph had me shaking my head.
Old 05-01-2013, 11:15 PM
  #15  
Senior Member
 
SultanGris's Avatar
 
Join Date: Dec 2010
Location: North Dakota
Posts: 7,877
Received 366 Likes on 284 Posts
Default

Never heard of a paper map huh? Lol
Old 05-01-2013, 11:16 PM
  #16  
Senior Member
 
Crazyhorse712's Avatar
 
Join Date: Dec 2012
Location: Monroe, LA
Posts: 184
Received 9 Likes on 9 Posts

Default

I have no idea what you guys are talking about, but I've only had one problem. Like another poster said, my radio won't come on and I have to use the voice command to get it to work. Other than that, no problems and I actually like it.
Old 05-01-2013, 11:34 PM
  #17  
Senior Member
 
beakie's Avatar
 
Join Date: Dec 2012
Location: Courtice, Ontario
Posts: 186
Likes: 0
Received 29 Likes on 22 Posts
Default

Originally Posted by btexan
In my 26 years of owning a system integration Var we can say the only OS that could run for years was Netware. 3 yrs uptime on a ms box yea right, considering most updates require a restart to apply.

The rest of your post may be accurate, but your first paragraph had me shaking my head.
back when I used to care for, and use MS, I had atleast 2 boxes that ran for over 18months without reboots (on mIRC stats were a big deal back then too)... they key... don't update MS.

when something works, why mess with it? I ran MS Windows 2k Pro for years without updating it because I was happy with how I had it set up. unfortunately most MS crap doesn't work out of the box, so they constantly mess with it... which means rebooting.


anyway, back on topic... the more I read about these problems the more I am glad I stuck with the basic radio.
Old 05-02-2013, 07:27 AM
  #18  
Senior Member
Thread Starter
 
nullname's Avatar
 
Join Date: Jul 2012
Posts: 212
Received 22 Likes on 18 Posts
Default

Originally Posted by SultanGris
Never heard of a paper map huh? Lol
Sure I have, use them all the time and i keep them in the pockets behind the seats. This is analogous to running out of toilet paper, I'd swap in a new roll but obviously you'd just use your bare hand.
Old 05-02-2013, 08:17 AM
  #19  
Senior Member
Thread Starter
 
nullname's Avatar
 
Join Date: Jul 2012
Posts: 212
Received 22 Likes on 18 Posts
Default

Originally Posted by OddBall
Most likely the reboots are caused by a fatal hardware error, like a double word offset memory or non-correctable memory error, bad RAM, etc... or even a known bug. The O/S has to panic and crash to maintain data integrity. Unfortunately you might need to take it to someone that can see if it logged any errors when it crashed.
As an assembly language programmer this statement is likely what is going on. Needing to periodically restart or reboot a system is indicative of an underlying software issue. Rebooting is not a maintenance task like changing the oil.
Old 05-02-2013, 09:07 AM
  #20  
Senior Member
 
flyingpostman's Avatar
 
Join Date: Feb 2013
Location: Caledon, Ontario
Posts: 170
Received 12 Likes on 9 Posts

Default

I was driving home yesterday and the entertainment part of Sync wouldn't turn on. Nav, Phone, and Climate worked but the Entertainment wouldn't power on via the screen power button or the volume **** power button. Got home and cycled the key and it worked again...


Quick Reply: Why Microsoft is Unreliable



All times are GMT -4. The time now is 07:22 PM.