Maybe if I give a couple of examples it will explain my question better. I am a Lead Developer and I've noticed that frequently it's difficult to estimate the amount of time troubleshooting and resolving a problem on an application will take. Frequently, we think an application error is being caused by one thing but then you start working on it and it becomes evident that it's likely something else that is much more complicated to resolve. It probably doesn't help that many of our developers are on multiple sprints so switching gears is not so easy.
I will give another example that might help explain the predicament better. Let's say you take your car to the auto shop because your a/c is broken and while they're trying to fix the a/c, they discover that it's not working because of a serious electrical problem that's actually much more complicated and need to keep your car for much longer than initially anticipated.
What do you do in these situations? Do you update the story/tasks mid sprint to more accurately reflect what it is that you are doing? Do you keep working and update things after the fact? Or maybe there's some other technique I'm not familiar with? I'm no scrum master but I've been a developer for many years and I know this problem is quite common.