Jump to content

1.8.1 Release Candidate 1 (build 12549)

Firon

By Firon
in Announcements

Recommended Posts

  • Replies 547
  • Created
  • Last Reply

Top Posters In This Topic

Popular Days

Top Posters In This Topic

Popular Days

Greg Hazel Advanced Member

Greg Hazel

Posted
Posted
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.

Link to comment
Share on other sites
Greg Hazel Advanced Member

Greg Hazel

Posted
Posted
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.

Link to comment
Share on other sites
Lim-Dul Member

Lim-Dul

Posted
Posted

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).

Link to comment
Share on other sites
fowl Advanced Member

fowl

Posted
Posted
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?)

Link to comment
Share on other sites
fowl Advanced Member

fowl

Posted
Posted
- 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)

Link to comment
Share on other sites
gLes Member

gLes

Posted
Posted
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 :)

Link to comment
Share on other sites
Lim-Dul Member

Lim-Dul

Posted
Posted

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...

Link to comment
Share on other sites
gLes Member

gLes

Posted
Posted

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...

Link to comment
Share on other sites
Greg Hazel Advanced Member

Greg Hazel

Posted
Posted
- 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!

Link to comment
Share on other sites
Greg Hazel Advanced Member

Greg Hazel

Posted
Posted
- 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.

Link to comment
Share on other sites
Lim-Dul Member

Lim-Dul

Posted
Posted

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. ;-)

Link to comment
Share on other sites

Archived

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

Go to topic listing
×
×
  • Create New...