Archived

This topic is now archived and is closed to further replies.

Firon

1.8.1 Release Candidate 1 (build 12549)

Recommended Posts

I tried to update using the auto-update - uTorrent disappeared, and then nothing happened.

I later found this zombie: http://www.mediafire.com/?zqej2ljddoy

I killed it, and when I started uTorrent again it was at the latest version.

Edit: Relocate crash still happens: http://www.mediafire.com/?dhywoymymzn

The zombie was waiting for the other process to die and the file to become overwritable. It does eventually time out.

My guess is the relocate crash is a module or registry setting which breaks that kind of Windows dialog - it does not look like a uT bug.

Share this post


Link to post
Share on other sites
Again? I thought that was taken care of ages ago, I mean I haven't encountered such recently :)

Altough I may have, I have a dump that I didn't post because it was for an older build (11903), and I updated to a newer one right away, maybe it's the same cause:

http://www.mediafire.com/?xyv2zmimm1g

uTorrent is running fine ever since it restarted after the last crash. I don't know what triggered it, as in means of user interaction. uTorrent just updated to the newest build automatically and then I added a new torrent and it started downloading ok. Then after a couple of minutes, crash.

I'll install the uncompressed version and send you the dumps if this ever happens again. Is there anything else I can do? I have Visual Studio installed, so I can do a debugging locally, but I suppose you can get all that information out of the minidump.

ole32!CStdMarshal::UnchainIPIDEntries+0x14

ole32!CStdMarshal::ReleaseAllIPIDEntries+0x64

ole32!CStdMarshal::~CStdMarshal+0x14

ole32!CStdIdentity::~CStdIdentity+0xad

ole32!CStdIdentity::`vector deleting destructor'+0xd

ole32!CStdIdentity::CInternalUnk::Release+0x6d

rpcrt4!IUnknown_Release_Proxy+0x13

hnetcfg!CSharedAccessConnectionManager::StartSearch+0xda

hnetcfg!CSharedAccessConnectionManager::AsyncStartSearching+0x20

ntdll!RtlpTpWaitCallback+0x8f

ntdll!TppWaitpExecuteCallback+0xfe

ntdll!TppWorkerThread+0x545

kernel32!BaseThreadInitThunk+0xe

ntdll!__RtlUserThreadStart+0x23

ntdll!_RtlUserThreadStart+0x1b

Looks like a bug in Vista's "SharedAccessConnectionManager", whatever that is. Do you have any special net setup? Gateway, bridged, VPN, anything like that?

Oh hey look you reported this previously: http://forum.utorrent.com/viewtopic.php?pid=335934#p335934

Maybe try a re-install of Vista? I don't see this crashdump from anyone else.

Share this post


Link to post
Share on other sites
You have the "Vista bug". How often does it crash? Does 1.7.7 crash too?

Yeah, I was told a few pages before. =)

No, 1.7 didn't crash a single time for me so I prefer calling this the "1.8 bug". =)

Share this post


Link to post
Share on other sites
You have the "Vista bug". How often does it crash? Does 1.7.7 crash too?

Yeah, I was told a few pages before. =)

No, 1.7 didn't crash a single time for me so I prefer calling this the "1.8 bug". =)

How often does it crash?

Share this post


Link to post
Share on other sites

http://forum.utorrent.com/viewtopic.php?pid=359430#p359430

And

http://forum.utorrent.com/viewtopic.php?pid=359702#p359702

It's pretty random. Usually it doesn't crash when downloading (now I noticed that contrary to my previous statement it DOES crash when downloading from time to time) but it does when seeding or being inactive. Some additional info for the previous posts - I have NOD32 but it's version 3 (and I added uTorrent to its exceptions like I wrote before).

Share this post


Link to post
Share on other sites

I have windows vista sp1 this build works as i want :P

but when i open utorrent i see in the logger that ipv6 is installed

21154511vt9.jpg

but it doesn't off like what in this picture

Share this post


Link to post
Share on other sites

The button is greyed out if you have a valid Teredo address. As Firon said, it stays lit if you do not, to allow you to reset the Teredo settings.

Share this post


Link to post
Share on other sites
My guess is the relocate crash is a module or registry setting which breaks that kind of Windows dialog - it does not look like a uT bug.

Shouldn't other apps and dialogs within µTorrent be effected then?

Anyway, do you have any suggestions to what I need to change? Even if it's not a µTorrent bug, I'd still like to resolve it. Would an uncompressed build help? (it that what is causing µTorrent's crash dump dialog?)

Share this post


Link to post
Share on other sites
- Fix: store .torrents from magnet URIs in correct storage path

This problem is still present. I have program settings stored along with executable. .torrent files downloaded via magnet links are also stored there instead of directory specified in Preferences.

Share this post


Link to post
Share on other sites
- Feature: diskio.no_zero, to avoid zeroing a file during allocation, where available (>= XP)

Will this be default any time soon? Are there disadvantages other than being less-broadly tested?

(I'm assuming this the reason for this feature is a performance improvement)

Share this post


Link to post
Share on other sites
alus wrote:

Looks like a bug in Vista's "SharedAccessConnectionManager", whatever that is. Do you have any special net setup? Gateway, bridged, VPN, anything like that?

Oh hey look you reported this previously: http://forum.utorrent.com/viewtopic.php … 34#p335934

Maybe try a re-install of Vista? I don't see this crashdump from anyone else.

Yeah I've had this thing for a while now, and just keep getting it.

My PC is connected to the internet via a router. I've got no ICS or anything else special configured, maybe except that I've got Virtual PC 2007 installed and that installs a network filter thingy for itself, but VPC is usually not running when uTorrent crashes.

These crashes have become quite rare recently. The last time I reported it it still occured once or twice a week, now this one had been only the second in two months.

I have another computer here where Vista has just been reinstalled with SP1, I'm not the main user, but noone reported any crashes from uTorrent and I see no crashdumps.

Actually I can totally live with this as long as its not too frequent, recovery is quite fast, I just thought you'd like to get to the bottom of this. As the matter of fact you have. You found that the bug is in hnetcfg.dll, which is non of your responsibility. You could either do a workaround somehow, or send the debug information to Microsoft for them to sort it out :)

Update

Got you another live one: http://www.mediafire.com/?ttnzxzzvzmo

This happened a little while after upgrading to the newest build (12320). After this I installed the uncompressed build.

What's peculiar is that while the crash dialog came up uTorrent itself was working ok in the background, it was responsive and everything. It only crashed after I clicked on a button in the crash dialog. I clicked on the bottom "Do nothing" option and then the Windows crash dialog took over. I tried debugging but I didn't get any smarter than with the .dmp file :)

Share this post


Link to post
Share on other sites

By the way - I just noticed one thing. When uTorrent "crashes" I, of course, get your custom "what do you want to do today" © window. However, the program doesn't actually feel like crashing - I never get any SYSTEM message that the application crashed AND I can keep the crashed window opened indefinitely while uTorrent functions perfectly fine in the background downloading and seeding and whatever else you use it for. ;-)

Seriously, this seems less and less like a Vista bug and more like overzealous anti-crash protection or something. :-D

P.S. Oh, gLes mentioned the same thing above. However, I don't even get the system crash warning afterwards...

Share this post


Link to post
Share on other sites

No, I'm sure it's some kind of unhandled exception in hnetcfg.dll, but this situation seems suitable for some kind of workaround, you just have to identify this crash, and of course it also matters whether it has any consequences if left unhandled...

Share this post


Link to post
Share on other sites
- Fix: store .torrents from magnet URIs in correct storage path

This problem is still present. I have program settings stored along with executable. .torrent files downloaded via magnet links are also stored there instead of directory specified in Preferences.

Er, yeah. There was a bug there - fixed, thanks!

Share this post


Link to post
Share on other sites

Every time I update, all my torrents recheck. Is this intentional or a bug? Either way its a real waste of resources especially for extremely large torrents.

Share this post


Link to post
Share on other sites
- Feature: diskio.no_zero' date=' to avoid zeroing a file during allocation, where available (>= XP)[/quote']

Will this be default any time soon? Are there disadvantages other than being less-broadly tested?

(I'm assuming this the reason for this feature is a performance improvement)

Yes, it was added for the performance benefits. There is a slight hesitation with making it on by default. It goes something like this:

If SetFileValidData is used on a file, the potential performance gain is obtained by not filling the allocated clusters for the file with zeros. Therefore, reading from the file will return whatever the allocated clusters contain, potentially content from other users. This is not necessarily a security issue at this point, because the caller needs to have SE_MANAGE_VOLUME_NAME privilege for SetFileValidData to succeed, and all data on disk can be read by such users. However, this caller can inadvertently expose this data to other users that cannot acquire the SE_MANAGE_VOLUME_PRIVILEGE privilege if the following holds:

- If the file was not opened with a sharing mode that denies other readers, a nonprivileged user can open it and read the exposed data.

- If the system stops responding before the caller finishes writing up the ValidDataLength supplied in the call, then, on a reboot, such a nonprivileged user can open the file and read exposed content.

Share this post


Link to post
Share on other sites
Every time I update, all my torrents recheck. Is this intentional or a bug? Either way its a real waste of resources especially for extremely large torrents.

Have you tried enabling bt.graceful_shutdown?

Share this post


Link to post
Share on other sites

No. But then again Im not really familiar with any of the advanced settings. Anyhow, it shouldnt happen with the default settings

Share this post


Link to post
Share on other sites

Hmmmm... The latest version of uTorrent hasn't crashed for the last 6 hours. I'm getting suspicious, especially since it's inactive, so in the state that made it crash non-stop before.

Update: OK, I decided to relaunch uTorrent since it obviously didn't want to crash. I'm "happily" reporting that this indeed made uTorrent crash almost immediately after relaunch. ;-)

Share this post


Link to post
Share on other sites
Guest
This topic is now closed to further replies.