Jump to content

Greg Hazel

Established Members
 View Profile  See their activity

  • Posts

    725

  • Joined

  • Last visited

 Content Type 

Posts posted by Greg Hazel

  4. 1.8.1 Release Candidate 1 (build 12549)

    in Announcements

    Posted

    The newest version (12495) should fix this, even if UPnP is enabled.

    well, i'm up, and µtorrent is still running :)

    BUT, i must say, upgrading is the first thing i did when these crashes were occuring

    so i already was running build 12495, and the crashes still happened ...

    Can you post your crash dumps? How do you know it's the "Vista bug"?

  6. 1.8.1 Release Candidate 1 (build 12549)

    in Announcements

    Posted

    - Fix: avoid duplicate connections with the same ID

    What did this cause and what does it effect now ?

    uTorrent mostly protected against this - if an outgoing connection was made and a previous connection (incoming or outgoing) to the same peer ID already existed, it would drop the new connection. The missing piece was if two incoming connections from the same peer ID arrived, it would not drop one of them. So in some cases two connections to the same peer, one over IPv4 and one over IPv6 for example, could be made.

    The new behaviour is to always enforce one connection per peer ID. This is in addition to allow_same_ip.

  11. 1.8.1 Release Candidate 1 (build 12549)

    in Announcements

    Posted

    Hello,

    sr.dll is part of Google Chrome:

    C:\Documents and Settings\*******\Local Settings\Application Data\Google\Chrome\Application\0.2.149.30\Locales

    And do you want to tell me what UTorrent crashed because of Google Chrome?

    That minidump was not a uTorrent crash, it was a Windows crash. Yes, I believe the "sr" module, whatever that is, was involved in the Windows crash.

  12. 1.8.1 Release Candidate 1 (build 12549)

    in Announcements

    Posted

    Firon,

    I have latest version of utorrent (12323), and i getting what problem in 12323 to. I mean what i was getting what problem from time i started using utorrent (v1.7).

    And yes, i got what crash after i tryed to open folder using Utorrent!

    I got what problem witch UTorrent not one time...

    Here is mini dump

    http://www.filefactory.com/file/52a3d6/n/Mini092608-01_dmp

    f7981a40 8054a583 nt!KeBugCheckEx+0x1b
    f7981a90 f722dac9 nt!ExFreePoolWithTag+0x2a3
    f7981aa0 f7235b46 Fastfat!FatFreeFcb+0x10
    f7981aac f723201a Fastfat!FatDeleteCcb_Real+0x15
    f7981b3c f723185c Fastfat!FatCommonClose+0x1b2
    f7981ba0 804eeeb1 Fastfat!FatFsdClose+0xbd
    f7981bb0 f7250459 nt!IopfCallDriver+0x31
    WARNING: Stack unwind information not available. Following frames may be wrong.
    f7981bb8 804eeeb1 sr+0x459
    f7981c0c 804eeeb1 nt!IopfCallDriver+0x31
    f7981c1c 805827bc nt!IopfCallDriver+0x31
    f7981c54 805b9e2d nt!IopDeleteFile+0x132
    f7981c70 805257b8 nt!ObpRemoveObjectRoutine+0xdf
    f7981c88 804e1b6e nt!ObfDereferenceObject+0x4c
    f7981c8c 804e1ab6 nt!CcPerformReadAhead+0x330
    f7981d34 804e7062 nt!CcPerformReadAhead+0x278
    f7981d7c 80537757 nt!CcWorkerThread+0x150
    f7981dac 805ce794 nt!ExpWorkerThread+0xef
    f7981ddc 805450ce nt!PspSystemThreadStartup+0x34
    00000000 00000000 nt!KiThreadStartup+0x16

    What is "sr"? sr.dll? Do you have that on your system?

    Anyway, not a uT issue.

  16. 1.8.1 Release Candidate 1 (build 12549)

    in Announcements

    Posted

    I have a completely different router (and with custom firmware to boot!) and experience the same crashes so it might not be router related. And yes, UPnP SEEMED to work correctly (that is, the ports were opened) as well.

    Now I know how to reproduce the bug - I don't have to REBOOT the router - I just need to close the ports uTorrent opened with UPnP. uTorrent apparently crashes each time it tries to set UPnP (or do sth. with it, dunno) - both on the router and, uhm, through Vista - the first time and ever after. Once the ports are set the program can apparently function normally until the next time it "tries to do something".

    It might very well be a bug in the Vista UPnP API - perhaps uTorrent uses some functions correctly but the OS handles them in a non-documented or simply buggy way.

    Fantastic! Can you narrow down the build where it started?

  18. 1.8.1 Release Candidate 1 (build 12549)

    in Announcements

    Posted

    I just finished setting up a FRITZ!Box WLAN 3270 Router which supports UPnP (my previous router did not) so I enabled UPnP port mapping in µTorrent (v1.8.1 b12323) and got a crash! I downloaded the uncompressed version, tried again, and got another crash:

    I am running Vista Ultimate x86 SP1, so perhaps this is the famous "Vista bug"?

    Problem Event Name: APPCRASH

    Application Name: utorrent.exe

    Application Version: 1.8.1.12323

    Application Timestamp: 48d6d81e

    Fault Module Name: hnetcfg.dll_unloaded

    Best Regards, Joe

    Indeed, this dump is a "Vista bug" crash. See "Fault Module Name: hnetcfg.dll_unloaded" there as well.

  21. 1.8.1 Release Candidate 1 (build 12549)

    in Announcements

    Posted

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

    Well, the problem is there was a significant amount of outstanding disk IO. So much that 10 seconds was not sufficient for it to complete. bt.graceful_shutdown waits until it has all finished, but that could take a very long time. It's a trade-off between updating fairly fast and then rechecking, vs. taking a long time to update then not needing to recheck.

  23. 1.8.1 Release Candidate 1 (build 12549)

    in Announcements

    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.

×
×
  • Create New...