When closing X - DBG with the window dump for example in text mode., the rerun and select Hex dump window is not displayed correctly.

Edited June 6, 20169 yr by sstrato

@sstrato I cannot reproduce your issue, could you make a screen recording showing how you got this to happen?

Ok.

video.wmv

It is not serious but it is annoying.

Edited June 9, 20169 yr by sstrato

continuous error in the last snapshot.
There is no solution?

The error occurs from changes snapshot 517.

step over step into is very slow. Especially within the DLL

Edited June 12, 20169 yr by sstrato

@sstrato There are a lot of issues and it's really hard to keep track of everything, especially with many contributions. For now I disabled column saving on the CPUDump it should fix your issues.

I'm aware of the step performance issue, but it's really hard to pinpoint the performance bottlenecks. I fixed various but the drawing stays bottlenecked and that needs reworking.

11 hours ago, Mr. eXoDia said:

@sstrato There are a lot of issues and it's really hard to keep track of everything, especially with many contributions. For now I disabled column saving on the CPUDump it should fix your issues.

I'm aware of the step performance issue, but it's really hard to pinpoint the performance bottlenecks. I fixed various but the drawing stays bottlenecked and that needs reworking.

The problem continues.

Video error Dump.

Error_dump.wmv

When you run any program on XP hangs.

Appears to work fine here:

Your issue with the dump window should also be fixed now.

Edited June 24, 20169 yr by Mr. eXoDia

X32 Windows XP to load any program crashes.

@sstrato: at least show *where* it crashes..  "Haga clic aqui" and copy-paste the exception information. 

Only it occurs in XP with any program that attempts to load.

crash_XP-error.wmv

Edited June 24, 20169 yr by sstrato

Did you even read my previous post? Here, I made a pretty picture for you:

Spoiler

1) Click on the "haga clic aqui", and copy-paste the entire information about the crash from the window that will open. It will look like this:

If you click "click here" one more time, it will look like this:

If you don't do that, nobody can guess what's happening on your computer, as apparently it works fine for Mr. eXoDia.

 

2) Also, your status bar says that ScyllaHide can't load properly on your machine. Try disabling ScyllaHide and see if that fixes the problems.

Clean boot without plugins.
files generated error.

error.rar

Windows 7 seems to work well.

Edited June 24, 20169 yr by sstrato

It looks like bug in calling devicenameresolver (its source is not distributed with x32dbg, but a separate project at https://bitbucket.org/mrexodia/devicenameresolver/):

__declspec(dllexport) bool DevicePathFromFileHandleW(HANDLE hFile, wchar_t* szDevicePath, size_t nSize)
{
    NativeWinApi::initialize();
    ULONG ReturnLength;
    bool bRet=false;
    if(NativeWinApi::NtQueryObject(hFile, ObjectNameInformation, 0, 0, &ReturnLength)==STATUS_INFO_LENGTH_MISMATCH)
    {
        ReturnLength+=0x2000; //on Windows XP SP3 ReturnLength will not be set just add some buffer space to fix this
        POBJECT_NAME_INFORMATION NameInformation=(POBJECT_NAME_INFORMATION)GlobalAlloc(0, ReturnLength);
        if(NativeWinApi::NtQueryObject(hFile, ObjectNameInformation, NameInformation, ReturnLength, 0)==STATUS_SUCCESS)
        {
            NameInformation->Name.Buffer[NameInformation->Name.Length/2]=L'\0'; //null-terminate the UNICODE_STRING
            if(wcslen(NameInformation->Name.Buffer)<nSize)  <--- compare length in chars vs. length in bytes?
            {
                wcscpy_s(szDevicePath, nSize/sizeof(wchar_t), NameInformation->Name.Buffer);   <---- calls wcscpy_s with wrong size and overflows buffer?
                bRet=true;
            }
        }
        GlobalFree(NameInformation);
    }

It only happens when you have some weird devices in your system, as I can't reproduce it in my VMWare..  

In either case, it's something Mr.eXodia should look at and fix.

 

EDIT: I quickly made a binary patch for devicenameresolver.dll - could you please try it and see if that helps? I'm not 100% sure it's a correct patch, but worth a try.

DeviceNameResolver.zip

Edited June 24, 20169 yr by kao

1 hour ago, kao said:

It looks like bug in calling devicenameresolver (its source is not distributed with x32dbg, but a separate project at https://bitbucket.org/mrexodia/devicenameresolver/):

__declspec(dllexport) bool DevicePathFromFileHandleW(HANDLE hFile, wchar_t* szDevicePath, size_t nSize)
{
    NativeWinApi::initialize();
    ULONG ReturnLength;
    bool bRet=false;
    if(NativeWinApi::NtQueryObject(hFile, ObjectNameInformation, 0, 0, &ReturnLength)==STATUS_INFO_LENGTH_MISMATCH)
    {
        ReturnLength+=0x2000; //on Windows XP SP3 ReturnLength will not be set just add some buffer space to fix this
        POBJECT_NAME_INFORMATION NameInformation=(POBJECT_NAME_INFORMATION)GlobalAlloc(0, ReturnLength);
        if(NativeWinApi::NtQueryObject(hFile, ObjectNameInformation, NameInformation, ReturnLength, 0)==STATUS_SUCCESS)
        {
            NameInformation->Name.Buffer[NameInformation->Name.Length/2]=L'\0'; //null-terminate the UNICODE_STRING
            if(wcslen(NameInformation->Name.Buffer)<nSize)  <--- compare length in chars vs. length in bytes?
            {
                wcscpy_s(szDevicePath, nSize/sizeof(wchar_t), NameInformation->Name.Buffer);   <---- calls wcscpy_s with wrong size and overflows buffer?
                bRet=true;
            }
        }
        GlobalFree(NameInformation);
    }

It only happens when you have some weird devices in your system, as I can't reproduce it in my VMWare..  

In either case, it's something Mr.eXodia should look at and fix.

 

EDIT: I quickly made a binary patch for devicenameresolver.dll - could you please try it and see if that helps? I'm not 100% sure it's a correct patch, but worth a try.

DeviceNameResolver.zip

It works perfectly, thanks.

 

 

@kao Did you patch the buffer size or something? I'm notoriously bad with UNICODE_STRING (causes of most BSODs in TitanHide) so maybe something goes wrong there too..

I changed it to:

if(wcslen(NameInformation->Name.Buffer)<nSize)
{
   wcscpy_s(szDevicePath, nSize, NameInformation->Name.Buffer);
   bRet=true;
}

I'm still not sure if that's entirely correct - you should take a look at all those calls and buffer sizes, probably under debugger.

As for me, I prefer to name variables like nSizeInChars or nSizeInBytes. That way I know what exactly I'm expected to pass to that API.  

Yeah that's quite the mess. The entire code is completely screwed up. I will do a 'rewrite' and post an updated version here.

EDIT: damn, I forgot how fast VS2010 was...

EDIT2: should be fixed now, available on http://releases.x64dbg.com when http://jenkins.x64dbg.com/job/vs13/587/console is finished.

Edited June 26, 20169 yr by Mr. eXoDia