Bass.dll V2.4 Download
Leocricia Flinchum
Errors related to bass.dll can arise for a few different different reasons. For instance, a faulty application, bass.dll has been deleted or misplaced, corrupted by malicious software present on your PC or a damaged Windows registry.
In the vast majority of cases, the solution is to properly reinstall bass.dll on your PC, to the Windows system folder. Alternatively, some programs, notably PC games, require that the DLL file is placed in the game/application installation folder.
Do you have information that we do not?
Did our advice help or did we miss something?
Our Forum is where you can get help from both qualified tech specialists and the community at large. Sign up, post your questions, and get updates straight to your inbox.
I'm trying to use functions from bass.dll that returns a value.
However the proc always return -1 and with error code 5, which means the handle is invalid.
So does handle i got from CLEO is different from handle used in bass.dll?
Or is there's anything else i miss?
Now i'm not actually a knowledgeable coder, so i have lot of things i don't understand when it comes to actual coding outside of scm.
One of functions, BASS_Bytes2Seconds requires a qword and returns a double.
Yes. The CLEO sound system is a interface to BASS. The handle returned by opcodes 0x0AAC and 0x0AC1 can not be directly used by BASS API because it's a address pointing to a CAudioStream or C3dAudioStream object (concept of CLEO).
Considering my lack of knowledge around audiostream and bass.dll, I'll take my time to either figure to the handle from cleo's stream or streaming audio from BASS_StreamCreateFile (although its kinda redundant to do it in cleo).
Perhaps have another value at 0x00 offset, so 0x04 potentially would be a HSTREAM. I have seen the CAudioStream class from CLEO 4(1/2) SDK, it had only hBassStream, uState e bOk; the remaining items are functions. I will try to find the CLEO SDK. It's hard to find anything in my HDD.
well, idk if function calling opcodes support returning floating point values, but you can write some sort of wrapper which will return double like int (float in eax). Not sure about using doubles in cleo, so theres also to float conversion.
It's totally wrong.
If you raises the pitch of a music, literally all notes will be raised and all song will be with wrong melody.
And stereo vs mono there is nothing to do with bass. Mono, the song plays in just 1 channel (so left and right is the same sound) and stereo is 2 (different sounds in each side, make it possible to create something immersive, separate the focus sound from ambient sound etc), nothing else.
After too much time, I finally got some time to examine a problem that was puzzling me since the very beginning. Why do you have to "tell" DxWnd about the presence of certain functionalities, like telling that the DirectX version has to be 1-6 or 7 or 8 or 9 rather than detected automatically?
DxWnd already handles a certain number of reasons why it should hook modules that are not immediately visible in the PE table of the executable: namely:
1) modules loaded dynamically through LocadLibrary calls
2) modules loaded implicitly by COM calls like QueryInterface or CoCreateInstance
I got a good test case: "Genso Suikoden 2". This asian RPG game uses D3D8 and you have to select DirectX hook version 8 to get DxWnd handling it at least partially (the game is not fully playable so far ..).
Peeking inside the PE and DxWnd logic I found that D3D8.dll is buried under a number of dependencies (see table below) and DxWnd is NOT able to scan the PE recursively, it currently stops to the first level, and this is not enough!
So I changed the DxWnd scan login in this experimental release v2.05.35, posted here for some testing.
The recursion logic is not trivial, since the system libraries have crossed dependencies that easily bring endless loops in the search. So, the procedure has a dedicated stack to keep track of the "visited" modules to avoid to search them more than once and enter possible endless loops.
But the gain is worth the risk: this way there should be a certain number of benefits:
1) the DirectX version selector should become useless and obsolete
2) the search should be faster and more accurate - no more useless attempts to hook dlls that are not present
3) hooking of calls wherever in the executable, no matter which module is calling them
4) also the "Hook / Additional modules" field should become useless, DxWnd should reach the module automatically
The game is not fixed by the new hook schema because it is obfuscated, so the scan procedure can't find all the interesting calls. Anyway, since the obfuscation leaves at least one reference for each DLL (see screenshot - with the only exception of kernel32.dll where the 3 calls are needed to load all other obfuscated ones) and I don't see there any reference to d3d8, I wonder if this game would be hooked correctly even if not obfuscated.
Thinking about that, I found several "weak points" in my logic:
1) the DLL loaded dynamically use the old non-recursive schema. I'm going to fix this right away!
2) some calls could be loaded by VB (Visual Basic) calls that I'm not sure they are correctly handled so far (see the reference to msvbvm.dll)
3) some COM objects could be created by CoCreateObject (handled so far...) and this new call CLSIDFromProgIDEx that found in the logs and still has to be investigated.
In conclusion, there are a few things we can draw:
1) to test the new hook schema, if it doesn't work one should set an early hook mode ("Inject suspended process")
2) obfuscated programs are good candidates for testing. In this case, if the hook doesn't work one should try also setting the "Hot patch" flag.
3) Programs using VB are again good candidates for testing.
4) Xtreme Tankz Madness 2 was a very good candidate: it resisted the new hook schema despite setting early hook and hot patch. Unless I can find the flaw and fix it, this is a good reason to keep the DirectX Version Hook selector (sic!).
I fixed the source code for hooking in dynamic loading, but XTM2 still refuses to cooperate. Somehow, this was expected, because no matter how deeply I try to navigate the module dependencies, I NEVER find ddraw.dll in anyone of the modules loaded. This means that there must be some other way to load ddraw that DxWnd still doesn't handle. I recovered the old schema adding this logic to the new one: the result should be (tests will tell!) a better yet schema but still not good enough for XTM2. Very interesting ....
More news. As said, there are two main problems to manage before we can say that the DirectX version selector and additional module are useless.
1) obfuscated programs
2) COM object creation through OLE calls (like CoCreateInstance).
Taking the obfuscation a little apart, the second problem had a very confusing solution in my source code. The problem seems to be that OLE could create a known COM object (like a DirectDraw session) or load a registered dll. and this case is more complex because every single game could create and register its own private dlls!
One example is XTM2 where ole loads the registered dlls dx7vb.dll and dx8vb.dll that are the VisualBasic6 wrappers for IDIrectDarw7 amd IDirect3D8 interfaces respectively, but I wouldn't like to have to list and handle all the VB interfaces for ddraw for each VB version ...
I think that in certain cases it should be necessary to look at the object GUID, compare it with the known ones and make the hook. This is what happens now.
In other cases, when you don't really know what OLE is linking to the program, maybe it could be wise to repeat the recursive hook for all new modules just in case.
I fixed some coding mess and tried to implement this idea. Unfortunately, today I'm on my Win7 pc where XTM2 doesn't work (who knows why, I did all as in my Win10 ...) so I can't test the new schema on the VB6 wrappers. But here is a list of games where the automatic hook is working:
1) it seems that I developed two more very dangerous tools to dump the header of a bitmap file (bmpdump.exe) and dump the audio tracks of a CD_ROM (bchunk.exe, more precisely my small changes to the original program). One of these is triggering the Kaspersky AV of SF and prevents the upload, so I used the usual trick of hiding the false-positive files within a password compressed archive, namely "viral_tools.rar". Likely you will have no need to extract these, but in case the password is "dxwnd".
2) the new schema seems great to me, but it still has some space for improvement. In particular, right now once a module is hooked it will be hooked no more, but that could be a perfectible choice. In any case, I didn't want to change something that works, just remember that as soon as we stumble in some strange case we may return on this point.
3) Again, the new GUID handling in OLE stuff is managing VB6 for one game, but it is likely that other cases with other langiages / releases / who knows may require considering more GUIDs to be processed. Stay tuned, eyes wide open on other weird cases.
They all works very well, apart form OpenGL version of Biofreaks, where a rendering flaw masks on black the moving polygons, so hiding some very interesting views (hem!) of the game. See screenshot ....
@huh: For some reason, the new hooking schema can't work with this game, I haven't succeeded to run it with DxWnd so far. The only way is to uncheck the "Hook / Hook all dlls" flag that is equivalent to use the old schema.
Curiously, the game crashes (and this wouldn't be a surprise) but tracking the game with OllyDBG step by step I saw that the game crashes within the DirectDrawCreate ddraw call.
Other oddity, in window mode the ship always quickly flies down and forward until it gets to the bottom-right corner of the window and it's not possible to move it in any other place, so the ship is quickly destroyed and the game level terminates.