Rollback Home Free Help

I'm really not in the business of making allegations, they're fact... here's the THREAD IceMan (HDS) started on the afternoon of 08Apr2014, the day the update was released into the wild. It wasn't until then that they realized the destructive nature of the original update.

The update was available for testing at MicroSloth's Spring Symposium in late March... primarily to allow Devs to test it with their systems. HDS either never knew about it or just figured it wouldn't be a problem. As a result, anybody running AUTOMATIC Updates on the morning of April 8th got their system torched by this update. And the problem wasn't just the fact that the MBR was "adjusted" by MS during the process as IceMan stated, MS actually resized the System partition to allow for the creation of a larger MS System Reserved Partition required by the update... that's what the MBR update was all about.

This update was a big one but anyone working outside of the OS was surely gonna get clobbered... that's why the 10-day test period for developers (there never usually is). W8.1 RBrx users never really had a chance... especially since very few of them actually visit the Forum where the 0-day announcement was made (not the 0-10 day announcement that should have been made).

There apparently have been additional updates that have done similar damage... that's why the new TURN OFF AUTOMATIC UPDATES "feature" in in the current RBrx release and the Forum thread for update checking had been established.

 

Yes, they are, so why does HDS not make them? If they did much of the complaints voiced above and elsewhere would stop. But no, HDS trumpets that Rx can recover a system from any conceivable problem.

I don't understand how you can support HDSs marketing claim and at the same time applaud the solutions to problems like that to which your comment was made.

Once again, If Rx has weaknesses HDS should make its users aware of them. HDS has, IMO, an obligation to its customers to educate them in how to protect themselves from Rxs vulnerabilities (and this does not stop at checking in at the forum before installing MS updates). What I think most of us are asking for is that HDS make it clear what a user needs to do to safely use Rx and then allow the potential user to decide if what is required is acceptable to them.....that and honesty in advertising.

Why this seems so hard for you to understand is beyond me.

 

Do you not understand why we have these doubts? Do you not understand how your insistence in the face of the information provided, which is clearly contrary to your (HDSs) position, undermines your credibility?

Its really simple, if the argument against HDS ownership and development of the products has any merit in your eyes then bring it to HDS management and ask them to explain it. Then let us know. If it does not have any merit then say why, that is prove the HDS assertion. If you are not prepared to do either then anything you say here, and elsewhere, will be tainted.

EDIT: perhaps HDS has not been straightforward with you Kurtis,,,,do you think this is a possibility?

 

I think I'll just shut up.

 

My point is that most users will never check the forum, so will not know that the updates have been cleared. RX would benefit from a pop-up on the taskbar informing the user that the updates have been cleared, and that they should now manually install the updates.

That said, I'm not sure if with updates set to manual windows pops-up a "updates now ready for installation" message or not - if so then some users would no doubt install them regardless of whether they have been cleared or not.

For me RX is essentially no longer Windows-compatible.

 

OK, trying to sum up everything said recently:

1) Problem: MS Updates occasionally trash RBRX.

Solution:The vendor can permanently overcome the issues with MS Updates, as Keata said, but hasn't.

They need to make the changes but they also need to know how to do that, and Keatah can help them, as Manolito said.

The developer(s) is probably a very nice person(s) who has no interest in marketing etc. but loves programming and would appreciate learning from one more experienced, and after all, isn't that why many of us visit Wilder's (to both teach and learn)?

Once this is done, problems 2) and 3) go away.


Until then:


2) Problem: HDS is 'late' in testing MS updates and issuing updates to their software.

Solution:Microsoft makes Updates available to software vendors 10 days before releasing them, as RBF said.

Those Updates should be tested by the vendor with both the retail and beta current released versions.


Perhaps HDS was not on Microsoft's 'mailing list' and therefore wasn't in a position to do the advanced testing.

Now that they are aware (Kurtis - ball in your court), HDS should contact MS, get on the 'mailing list' and do the testing before the MS Updates are released and release updates to HDS's software. Of course HDS would have to have copies of all MS current OSs for this testing (e.g. there are no Updates for XP and maybe none for Vista or W7, etc.) but the testing could be done initially by someone other than the developer, all they need to do is apply the Updates and see if RBRX crashes.


Caveat: It's the user's responsibility to keep the vendor's software at the current released version.
If a user elects to stay at a previous version then the user gives up the right to complain if there's a problem.

But, a user must know that there's an HDS update available and that it's critical to avoid an issue with MS Updates.


Until then:


3) Problem: Users aren't aware that MS Updates may trash the current RBRX.

Solution: The vendor could, in future versions, include code that 'calls home' to check not only for available updates to the vendor's software but also notifies the user of issues with MS Updates and warns users to delay installing said Updates (which may require a user to turn OFF automatic updates) until an update to the vendors software has been released and installed.

There's a problem that the volume of MS Updates may be large while only a single Update is a problem and it's installation should be delayed while the rest of the Updates can be installed, especially if they are Critical.

This would be a supplement to warnings on the vendor's web site.


And, regardless of the above:


4) RBRX and Drive Cloner should be a package.

RBRX shouldn't be sold alone, as said by several folks including myself and now Kurtis (Kurtis - another ball in your court).


5) Documentation about all this should be easily available to users.

If they ignore it, they are responsible.

My 2 cents...

 

Jwcca... that was actually 6-cents

Your ramblings above are taken in good faith... some thinking to do on everybody's part. Understand... there is NO MAILING LIST of MicroSloth's part, it is up to the vendor of Windows-based software to avail themselves of early releases of MS changes. When they have the potential of being "earth shaking," MS ALWAYS makes them available early (like a new complete OS) and it's clearly up to the vendors to avail themselves of these changes, there really is no excuse. When an OS is in BETA or "public view" before its official release for many months, there really is no vendor excuse for having their product NOT AVAILABLE when MS goes RTM (Release To Manufacturing) unless they have serious problems or don't plan to support it under the new/changes OS... NONE.

Contrary to what many will say... these types of issues ARE NOT Microsoft's FAULT.

 

I agree. blaming software developers are almost a moot point. Most end users who don't customize their computer or beef it up with an incredible amount of software will likely never see an issue. It's when computers have many different applications all somewhat conflicting with eachother or with Windows, etc. I always respect your approach Froggie as it's similar to mine, know the restrictions and work within them.

Cheers,

 

Heh, 3 times more valuable than I thought , still, in Canada, with no pennies anymore, both 2 cents and six cents get rounded down to 0 and 5...

Yeah, happens more and more with old age

HDS is based in Canada so I have at least some selfish reason to hope that they succeed and thus improve our Balance of Trade figures . Kurtis can facilitate getting Keatah and the HDS developer together to put the issue of MS Updates to rest.

And I also hope that your documentation gets included to avoid the other BMR issue.

J

 

daNILE is not just a river in Egypt, feigning IGNORance is a tactic employed by HDS and their employees when dealing with questions they really would not (or are plain not able to) deal with.

 

Yup! File a Support Ticket and let me know the Ticket ID and we'll take a look!

So if that is our strategy then why would they put me on here?

 

To do just your job...
To advertise,
to provide false information,
to diminish the problems caused by RollbackRX failures,
to fake an interest for people that had lost their data https://www.wilderssecurity.com/threads/re-rollback-rx.374675/page-2 ,
to fake a resolved problem case after your godsend intervention https://www.wilderssecurity.com/threads/rollback-has-crashed.374600/ ,
and to try to belittle anyone who dares to give a warning to the others.

Difference is that you are paid for posting here, while the "opposition" is not.

Panagiotis

 

It's up to you to use your initiative and, if filing a ticket is what it takes, then the ball is in your court, and that's what you should do, don't try to pass the responsibility off on me old boy, that won't stick.

I'd think it better to first talk to your developer to see if he's open minded to receiving help. If he is, only then send a PM to Keatah to see if he'll help. If he is, then set up a means for the two to work together. That's not a lot for you to do considering the potential benefits of getting that issue off the table here.

What are you likely to see with 'that look' that isn't blatantly obvious right now?

J

 

One of the first things that they teach lawyers is: "never ask a question to which you don't already know the answer..."

and the answer that proves the above reasoning is:

which is definitely a terrific example of a 'verbal blunt instrument'

 

Well if you don't want to file a ticket that's fine, but we need log files and I can't do that for you without being in front of your computer. So if someone needs help, they can file the ticket and give me the ticket ID. That's the best I can do for you.

 

Do it in front of your own company computer.

I don't need help, you do, so file the ticket yourself if that's what you need to do before you can talk to the developer....

I'm amazed that this is your response but then I'm an idealist that want's to look for the best in others, but I just can't find it in you when you say 'That's the best I can do for you'.

 

Thats a good question,,,,,,,why did they put you on here?

I look forward to your reply.

 

If I had to pick just one word to summarize everything that's been said by many, but especially Panagiotis in post 212 above, it would be 'propagandist'.

 

It's not that I don't mind filing the ticket, believe me it's not tough. It's that we need log files. Unless you email me your log files, then I could. My thinking is that it would be easier for you to do it, but if you'd like to do it that way I'm flexible.

 

Thats OK, I did not expect a reply,,,,thats the HDS way.

 

Kurtis go back and read how this all started.

I suggested that
1) you talk to your developer about the potential help by Keatah to eliminate Windows Updates causing problems for RbRx and,
2) if he/she is interested, then you contact Keatah and see if he's willing.

There are NO logs in that scenario, it's just a 5 minute conversation with your developer and maybe another 10 minutes to send and receive PMs to Keatah. Therefore there's no logs to attach to a ticket. (Unless you log your conversations with your developer and your time and the number of PMs that you send and receive). Get it?

Unless you pay better attention, you'll likely find that you'll end up losing.

 

We have the infrastructure in place to ensure that people aren't affected by Windows Updates. We change the settings of installation from automatic to manual. Giving you the opportunity to reach out to us or read our forums to find out if the Windows Update will affect it.

Of course, most customers use SCCM or a VM to test these updates first.

If Keatah has a suggestion he can email or PM me, but this is something we're already addressing.

 

But a user may simply change the option back to Auto, or do you keep changing it to manual?

How do they know to do that?

Do you mean that they use a VM to test the MS updates with RbRx?

Does 'addressing' = 'implementing'?

 

If someone changes it back to auto then what can we do? We make those changes, but if you change them back you're altering with the product and the changes we make. We will always try to help, but changing those settings to auto is a bad idea.

Most people will seek out the knowledge they don't have. That's why people use forums and other online resources

Many proactive users do. I myself never install an update until I have it tested in a VM environment; but you have to keep in mind that our product is mainly for corporate and educational markets that use SCCM. So majority of our users have something in place to prevent these updates from being fully executed. Many users on here try to make is seem like these updates are a widespread issue, and it's definitely a pain. However most people have infrastructure in place, and generally don't have a problem. It's a few end users, who we will always tell you whether you email us or go to our forums.

I by no means want it to seem like we're resting on our laurels, it's actually far from. It's that most of our users are mindful of these things, and a few users on Wilders will try to convince me and users on here that it's a major problem but it's common sense. If Microsoft is making changes to the infrastructure around which every program operates in, then certain programs could be affected. We don't know what it will do, all we can do is test the update and report it for the few users who rely on that knowledge.