Very true but I mean if the malware is in the signatures then it will be detected. If it's not listed in the signatures then yes it will get through unless a behavioural blocker blocks it at execution. I should have mentioned that bit before...
Not all of that is entirely true.
Normally security products start with the checksum hash detection - they either load in parts of their DB in memory at a time or work with other methods to query the database containing the signatures - and they often perform optimisations so the checksum detection's are towards newer threats, as opposed to wasting disk space on local signatures for malware that was in the wild 6 years ago.
After the checksum hash detection they have the static heuristics - now the static heuristics will involve generic signature detection and I consider this part of heuristics - and the heuristics can do a number of things: HEX detection (based on the bytes), scoring system (e.g. based on what functions are imported, strings within the binary, checking the PE File Header, and so on. Via static heuristics the security product can usually differ between a packed executable and a non-packed executable, via the HEX detection (for some packers), or via the imports (e.g. the file size is large but very few imports, especially functions like GetProcAddress and LoadLibraryA/W (both from Kernel32.dll)/PE File Header/Entropy level). As well as this, static heuristics can include auto-blocking based on the file-name (e.g. PE pretending to be SvcHost.exe, or another genuine windows program which it is not).
After the static detection methods (e.g. checksum hash detection & static heuristics methods), upon execution the executable may be submitted through a cloud network depending on it's file size (e.g. the smaller the file size the higher the chance it will be submitted to the cloud), assuming that specific security product contains some sort of cloud protection. However, the sample isn't always submitted to the cloud (e.g. if there is no behavioural cloud active there), but details related to the publisher of the digital signature may be queried on the cloud network for file reputation information (e.g. check if Adobe is in the trusted list on the cloud). There are numerous approaches for cloud protection.
After the cloud check-ups (if they are there), you will usually have the dynamic heuristics. The dynamic heuristics usually does things like monitor the behaviour of the program by injecting into it and setting user-mode hooks (especially for the first few minutes of execution at least, since malware typically tends to start with adding to start-up and querying details about the user/system, etc). Therefore, if the program launches and then instantly tries to access and perform modifications to the Master Boot Record, then the dynamic heuristics may intercept and auto-quarantine... Or the same logic for a hosts file modification.
That being said, most products move to either good dynamic heuristics or good BB/HIPS, as opposed to both, since they may not always mix well together. And users tend to want more control these days, therefore BB/HIPS is essentially dynamic heuristics, except you are controlling the decisions when specific behaviour is triggered such as AutoRun modifications, injection attempts, host file modifications, MBR access, keylogging attempts, etc.
Therefore moving back to the part I quoted, the Behaviour Blocker does not block at execution - it intercepts based on behaviour while it's attempting to execute (usually via API hooking) instead. And the HIPS does the same thing for it's own specific triggers, such as AutoRun modifications as an example.
Regarding signatures, you can literally make one small modification to the bytes in the file and then it will generate a new checksum hash, circumventing any checksum based detection for the current sample in AV databases. This is why most top vendors focus more on generic detection methods for signatures more than checksum detection's.
--------------------------------------------------
Now I've explained a bit about different stages, I can move back to the original topic discussion: if you are performing malware testing and the program fails to start-up (e.g. cannot run on the OS) then of course the dynamic heuristics or BB/HIPS system cannot interfere, because there is no reason for it to interfere, since the program wouldn't be attempting to do anything to trigger the dynamic heuristics or BB/HIPS (since the program failed to start-up/crashed before it could do anything).
That being said, some malicious software (well more common than not) will perform checks before it executes any malicious code to help determine whether it's running within a virtualised environment (e.g. Virtual Machine in VirtualBox or VMWare) or within a sandbox like Sandboxie (e.g. check for processes (e.g. Guest Additions), registry, etc). More advanced malware will also get the address of functions it may attempt to use, and then perform byte comparisons at the address of this function to determine whether the function prologue in memory has been manipulated (e.g. hooked)... And of course depending on the determination results, it may fake an alert/crash so it appears it isn't working. Malware authors don't want to infect Virtual Machines or execute malicious code within a sandbox unless they can exploit it, they want to infect the host machines.
Even in the case of a scenario as described above regarding VM/Sandbox awareness and fake error/crash; there is still no reason for BB/HIPS to interfere because it wouldn't be triggering anything for it to pop up and ask the user...
Hope the above cleared some things up.
Please feel free to leave any constructive criticisms or feedback - all is appreciated 
