2.7.0.0 installer consistently bluescreens Vista

[nxliinxlii]

The 2.7.0.0 installer consistently causes Vista Home Premium 32-bit to bluescreen just after copying filed, "Registering Files", and during or just after "Finalizing Install", when installing over 2.6.0.0 with the default settings except for unchecking UPnP discovery (I have manual port forwarding configured so don't need to use UPnP). Nothing else but Explorer running (and, in particular, 2.6.0.0 not running, nor had been since the previous reboot). I tried it twice with identical results.

This is unacceptable. Not only was this clearly not tested on a still very common operating system, and one that it purports to support, but there is no reason for Shareaza to even be capable of causing a blue screen. Causing a blue screen requires going into kernel mode and then f*#%@ing up in some manner, and the installer has no reason to be doing any futzing about in kernel mode. None of the other kernel-mode code involved (drivers) is a likely culprit, since everything else on the system in question works fine. Just not the 2.7.0.0 installer, which therefore is where the problem exists. In kernel-mode code. Which the 2.7.0.0 installer should have none of, even when run as administrator.

What gives?

[nxliinxlii]

I have since looked up the error code generated. The installer is, specifically, causing a stack overflow while in kernel mode, after displaying "Finalizing Install" and before displaying a success indication.

[nxliinxlii]

Additionally, the installer doesn't succeed and then crash. The shortcuts in the Start Menu don't work after your installer's botched attempt, and manually running the 2.7.0.0 executable (which *has* been installed) results in "Can't load metadata schema. Reinstall the application." or words to that effect. The schema directory has the same 150 files of mostly icons and XML as before, so it's not clear why it "can't load" it, suggesting that since the schema directory seems to be intact (and the files readable; I viewed one XML file in Notepad and it didn't look corrupt) the executable itself is not.

[nxliinxlii]

I restored a recent backup's Program Data/Shareaza and Program Files/Shareaza directories, as well as the hostcache.dat and discovery.dat files for AppData/Roaming/Shareaza, and have 2.6.0.0 working again, apparently without issues.

However, this sort of thing had better not happen to me again, ever. People trust that installers served from reputable websites like SourceForge will not crash their operating system and corrupt an installed application in such a manner; in short, trust that things downloaded from SourceForge will not behave like malware. Please get your house in order, and then let me know (with a followup to this thread saying so) when you have a 2.7.0.1 (or whatever) installer that has actually been tested on Windows Vista Home Premium 32-bit and that works reliably on that operating system. In particular, it should not cause stack overflows in the kernel during "Finalizing Install" after (or while) overwriting the Shareaza binary but before setting up the Start Menu shortcuts, as the current version does on that OS.

[dr-flay]

On the one hand I slightly agree with you, on the other I would say screaming and shouting, is not how you submit a bug-report.
That is how to get ignored by the Devs.

Also Malware is not generally designed to BSOD during install, or it would not be very useful to the author.
But without reporting any of the useful info on the BSOD you get, no-one can say what files may need updating or removing.

Vista. Does that still function? It must feel like weaving treacle if you don't reinstall every few months.
Vista usage is actually minimal. It is the least used Windows OS
http://wikipedia.org/wiki/Usage_share_o ... ng_systems

No one should be running Vista. It was a "mistake" of an OS, that requires more resources than any other.
Translate the name "Vista". It means "a nice view" or "looks nice".
At no point did MS think to name it the latin for "Works well".
It is the "red-headed step-child" of the computing world.
It was purely an attempt at competing with OSX, and so flawed it should have been put-down at birth.

Do yourself a favour and install XP or 7. You will then have a fast PC again, with loads of spare RAM.

Your issue sounds related to the problem I found when installing it on XP, as it bombs about the same point.
I am now happily using a previous debug version of 2.7 that does not crash.

I used "Dependency Walker" utility that is included with the support tools on a Windows disc.
This showed me that, at some point Shareaza was accessing a file that is part of DirectX 10 and above.

Shareaza crashes when triggering DLLs that are not distributed with Shareaza.
The DirectX layer can talk to hardware and therefore BSOD.

The issue we both will have, is because of the amount of extra crap installed in our systems.
There will be some wonky DLLs in any of our given PCs, and they will all be at different versions.
Once you open any program or DLL in "Dependency Walker" you will see how the problem is more likely to happen than not.
My XP spent a while faking Windows 7 (very nice ), so I had to patch Windows/DirectX to allow DX10.
I know my PC has extra files it should not, but I still required a newer version of a DLL for it to work properly, as the DLL i have is missing a function.
To disable the DX10 access on my PC, I renamed a bridge DLL that should not be on XP.

Access 1 single function in any given OS library, and you will see a cascade effect, where that 1 DLL requires a function in another DLL, so you load that DLL, then the functions in that DLL require the functions in another, and so on.
Before you know it you have loaded several megs of librarys, just to use 1 function.
Often some DLLs are not backward or forward compatible. That is why they are often stored in the program folder, rather than being placed in "system32"
There are several Microsoft DLLs that misbehave, so should never be put in the system folders.

The missing or broken function may never have been called by the original program, but can easily be the thing that bombs it.
If programmers do not write fall-back routines, then dead-ends are common.
Shareaza is a monster of a programming nightmare, as it requires dealing with many external things that are beyond the control of the developers (who are after-all, just amateur guys doing something they enjoy).

Try the debug build I am using on XP viewtopic.php?f=7&t=1577
Even CoDecs have the potential to crash a program or your PC, as many will try to access hardware decoding and functions.

[siavoshkc]

[raspopov]

[nxliinxlii]

Umm, it's a BSOD. Copy/paste, alt-printscreen, etc. don't work. I did look up the error code generated and determined that it indicated a stack overflow happening while in kernel mode, though.

Oddly there was no identification of the faulting module (vxd or similar) as there usually is with BSODs.

The BSOD is consistent, happening at the same point in the installer's progress every time (shortly after it says "Finalizing install"), and having the same content (error code, etc.) every time. It's not some fluke or one-off. Something in that installer results in a very dependable stack overflow in kernel mode when it's "finalizing install".

[raspopov]

[queueclimber]

memory.dmp ?

[nxliinxlii]

[raspopov]

[dr-flay]

If you have installed Windows from disc, you have the option of installing extra support tools.
C:\Program Files\Support Tools
Amongst these is a handy tool called "Dependency Walker".
You can use this to profile any EXE and see what files it is accessing.
Set it to dump the info to a log file.

It is probably worth getting the newer version 2.2 from the site anyway (now comes in 64-bit flavour)
http://www.dependencywalker.com

I have found occasionally that "profiling" a program has allowed it to crash gracefully, or even sometimes actually run and open.

[nxliinxlii]

OK, you've been alerted that the 2.7.0.0 installer fails, catastrophically, on an OS that's supposed to be supported and on which the 2.6.0.0 installer worked. You've been told that the error code, when looked up, indicated that it caused a stack overflow in kernel mode, just after saying "finalizing install" and after installing the .exe file but before creating the shortcut files -- that puts it in a narrow part of the overall install process.

Now, is someone going to either a) produce a 2.7.0.1 (or just a repackaged 2.7.0.0) whose installer works? Or else, tell me some simple thing I can do (registry tweak?) that will make the 2.7.0.0 installer work on my system?

[nxliinxlii]

[siavoshkc]

[ailurophobe]

http://support.microsoft.com/kb/315263#method2

Read the configure dump type. This should get you a memory dump of why BSOD happened. This is specifically designed for "system errors" so it should work.

queueclimber mentioned this few posts back, but maybe you missed it?

[smokex]

nxliinxlii: You have very rudely reported that there is an issue on an operating system that the primary developer has reported he uses to actually develop the application. This fact alone makes it highly likely that something you have done to your own computer is causing the problem.

Second, 2.7.0 is a debug release. If it were a true release, it would be reported on the Shareaza home page. Since it is a debug release, you should expect issues installing and running it. That's why we're testing it, because it has bugs, crashes, might eat your cat, etc..

Third, you have provided absolutely no information to tell us what could be wrong (write down the error code and send it to us here). How are we supposed to fix something if we have absolutely no information to track down the issue. We use the inno installer. All it does is copy the binaries and dlls over and registers the dlls with the system.

We will be glad to fix a problem if you can prove to us that we actually have one and its not your operating system that is messed up.