feat: Add handles entry by using undocumented ntdll functions to get the handles#78
Draft
supervoidcoder wants to merge 14 commits intomainfrom
Draft
feat: Add handles entry by using undocumented ntdll functions to get the handles#78supervoidcoder wants to merge 14 commits intomainfrom
supervoidcoder wants to merge 14 commits intomainfrom
Conversation
Contributor
|
Important Review skippedDraft detected. Please check the settings in the CodeRabbit UI or the You can disable this status message by setting the
✨ Finishing touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Owner
Author
|
@coderabbitai UGHHHHHHHHH what is going on |
Contributor
|
Tip For best results, initiate chat on the files or code changes. 🧩 Analysis chain🏁 Script executed: Length of output: 4245 🏁 Script executed: Length of output: 1145 🏁 Script executed: Length of output: 1784 🏁 Script executed: Length of output: 811 🏁 Script executed: Length of output: 261
Here's what you need to add around line 73 (after the existing function pointer typedefs): typedef NTSTATUS (NTAPI *_NtQuerySystemInformation)(
SYSTEM_INFORMATION_CLASS SystemInformationClass,
PVOID SystemInformation,
ULONG SystemInformationLength,
PULONG ReturnLength
);
typedef NTSTATUS (NTAPI *_NtDuplicateObject)(
HANDLE SourceProcessHandle,
HANDLE SourceHandle,
HANDLE TargetProcessHandle,
PHANDLE TargetHandle,
ACCESS_MASK DesiredAccess,
ULONG Attributes,
ULONG Options
);
typedef NTSTATUS (NTAPI *_NtQueryObject)(
HANDLE ObjectHandle,
OBJECT_INFORMATION_CLASS ObjectInformationClass,
PVOID ObjectInformation,
ULONG ObjectInformationLength,
PULONG ReturnLength
);Then at lines 1592-1597, you need to cast the _NtQuerySystemInformation NtQuerySystemInformation =
(_NtQuerySystemInformation)GetLibraryProcAddress("ntdll.dll", "NtQuerySystemInformation");
_NtDuplicateObject NtDuplicateObject =
(_NtDuplicateObject)GetLibraryProcAddress("ntdll.dll", "NtDuplicateObject");
_NtQueryObject NtQueryObject =
(_NtQueryObject)GetLibraryProcAddress("ntdll.dll", "NtQueryObject");Also, at line 1614, you need to cast the integer to the enum type: while ((status = NtQuerySystemInformation(
(SYSTEM_INFORMATION_CLASS)SystemHandleInformation,
handleInfo,
handleInfoSize,
NULL
)) == STATUS_INFO_LENGTH_MISMATCH)And at lines 1658, 1688, and 1698, cast the object information class constants: NtQueryObject(
dupHandle,
(OBJECT_INFORMATION_CLASS)ObjectTypeInformation,
objectTypeInfo,
0x1000,
NULL
)This follows the same pattern you used for the PEB reading functions! 🐰 🧠 Learnings used |
Owner
Author
|
@coderabbitai i knew those were missing, but i thought they would conflict with the existing NTSTATUS definitions? |
Contributor
|
Tip For best results, initiate chat on the files or code changes. 🧩 Analysis chain🏁 Script executed: Length of output: 1233
The NTSTATUS NtQuerySystemInformation(...); // regular function declarationYour typedefs define function pointer types, which are different. Following your existing pattern (I can see you use typedef NTSTATUS (NTAPI *pNtQuerySystemInformation)(
SYSTEM_INFORMATION_CLASS SystemInformationClass,
PVOID SystemInformation,
ULONG SystemInformationLength,
PULONG ReturnLength
);
typedef NTSTATUS (NTAPI *pNtDuplicateObject)(
HANDLE SourceProcessHandle,
HANDLE SourceHandle,
HANDLE TargetProcessHandle,
PHANDLE TargetHandle,
ACCESS_MASK DesiredAccess,
ULONG Attributes,
ULONG Options
);
typedef NTSTATUS (NTAPI *pNtQueryObject)(
HANDLE ObjectHandle,
OBJECT_INFORMATION_CLASS ObjectInformationClass,
PVOID ObjectInformation,
ULONG ObjectInformationLength,
PULONG ReturnLength
);Then at lines 1592-1597, declare variables using these types: pNtQuerySystemInformation NtQuerySystemInformation =
(pNtQuerySystemInformation)GetLibraryProcAddress("ntdll.dll", "NtQuerySystemInformation");
pNtDuplicateObject NtDuplicateObject =
(pNtDuplicateObject)GetLibraryProcAddress("ntdll.dll", "NtDuplicateObject");
pNtQueryObject NtQueryObject =
(pNtQueryObject)GetLibraryProcAddress("ntdll.dll", "NtQueryObject");No conflict because 🧠 Learnings used |
Owner
Author
|
@coderabbitai see it's still broken 😭 |
Contributor
|
Tip For best results, initiate chat on the files or code changes. 🧩 Analysis chain🏁 Script executed: Length of output: 4490
Here's the complete fix: First, move the GetLibraryProcAddress definition to BEFORE line 1590 (around line 1580 or so): PVOID GetLibraryProcAddress(const char* LibraryName, const char* ProcName) {
HMODULE hMod = GetModuleHandleA(LibraryName);
if (!hMod) {
hMod = LoadLibraryA(LibraryName);
if (!hMod) return nullptr;
}
return (PVOID)GetProcAddress(hMod, ProcName);
}Then at lines 1590-1595, rename the variables to avoid conflicts: _NtQuerySystemInformation pfnNtQuerySystemInformation =
(_NtQuerySystemInformation)GetLibraryProcAddress("ntdll.dll", "NtQuerySystemInformation");
_NtDuplicateObject pfnNtDuplicateObject =
(_NtDuplicateObject)GetLibraryProcAddress("ntdll.dll", "NtDuplicateObject");
_NtQueryObject pfnNtQueryObject =
(_NtQueryObject)GetLibraryProcAddress("ntdll.dll", "NtQueryObject");At lines 1623-1628 (inside ListProcHandles), add the casts: _NtQuerySystemInformation pfnNtQuerySystemInformation =
(_NtQuerySystemInformation)GetLibraryProcAddress("ntdll.dll", "NtQuerySystemInformation");
_NtDuplicateObject pfnNtDuplicateObject =
(_NtDuplicateObject)GetLibraryProcAddress("ntdll.dll", "NtDuplicateObject");
_NtQueryObject pfnNtQueryObject =
(_NtQueryObject)GetLibraryProcAddress("ntdll.dll", "NtQueryObject");At line 1673, cast the handle properly: if (!NT_SUCCESS(pfnNtDuplicateObject(
hproc,
(HANDLE)(ULONG_PTR)handle.Handle, // Cast USHORT to HANDLE
GetCurrentProcess(),
&dupHandle,
0,
0,
0And use the 🧠 Learnings used |
Owner
Author
|
@coderabbitai well it compiles now but it just does this: seems like it's just brute forcing through pointers/addresses |
Contributor
|
Tip For best results, initiate chat on the files or code changes. 🧩 Analysis chain🏁 Script executed: Length of output: 5591
1. The process handle needs PROCESS_DUP_HANDLE access When you open the process (wherever you call HANDLE hproc = OpenProcess(
PROCESS_QUERY_INFORMATION | PROCESS_VM_READ | PROCESS_DUP_HANDLE, // Add PROCESS_DUP_HANDLE!
FALSE,
pid
);2. NtDuplicateObject options parameter is wrong At line 1677, change the last parameter from if (!NT_SUCCESS(pfnNtDuplicateObject(
hproc,
(HANDLE)(ULONG_PTR)handle.Handle,
GetCurrentProcess(),
&dupHandle,
0,
0,
DUPLICATE_SAME_ACCESS // Change this from 0!
)))3. Add debugging to check if function pointers loaded Right after loading the function pointers (around line 1629), add: if (!pfnNtQuerySystemInformation || !pfnNtDuplicateObject || !pfnNtQueryObject) {
printf("Failed to load ntdll functions!\n");
return;
}4. Print the actual error code to see what's failing: Change line 1685 to: {
printf("[%#x] DuplicateObject failed: 0x%X\n", handle.Handle, status);
continue;
}Try these fixes! The most important one is adding 🧠 Learnings used |
Owner
Author
|
@coderabbitai I'll do that, but now that I see what happens when the handle doesn't have that permission, I think i'm either gonna scrap that stupid whiny "Error!" line or add some other form of error handling because half the time when you don't have admin, most processes won't let you have these permissions. unless PROCESS_DUP_HANDLE is compatible with the limited query too and doesn't require full reading but I doubt it |
Contributor
|
Tip For best results, initiate chat on the files or code changes.
Here's what I'd suggest for better error handling: Option 1: Silent failures with a summary int successCount = 0;
int failedCount = 0;
for (each handle) {
if (NT_SUCCESS(pfnNtDuplicateObject(...))) {
successCount++;
// Process the handle...
} else {
failedCount++;
continue; // Silently skip
}
}
printf("Handles: %d successful, %d failed\n", successCount, failedCount);Option 2: Only log "interesting" errors if (!NT_SUCCESS(status)) {
if (status != STATUS_ACCESS_DENIED && status != STATUS_INVALID_HANDLE) {
printf("[%#x] Unexpected error: 0x%X\n", handle.Handle, status);
}
continue;
}Option 3: Verbose mode flag if (!NT_SUCCESS(status)) {
if (verbose) {
printf("[%#x] Failed: 0x%X\n", handle.Handle, status);
}
continue;
}About PROCESS_DUP_HANDLE with limited permissions: Unfortunately, PROCESS_QUERY_LIMITED_INFORMATION only provides basic data access and won't help with handle duplication. Handle duplication is inherently a privileged operation—you're literally copying handles from another process's handle table into yours! I'd go with Option 2 personally—it keeps your output clean while still catching truly weird errors. 🐰 🧠 Learnings used |
Owner
Author
|
@coderabbitai i wonder how sysinternals handle does it then? that's weird... |
Owner
Author
|
@coderabbitai wait i'm stupid, handle still doesn't work with system processes which makes sense. Well, I know there is a function in the toolhelp32 api that gives you the count (without explicitly handing you the handles themselves) so we can do that as a fallback if the user isn't running it as admin |
Contributor
|
Tip For best results, initiate chat on the files or code changes. 🧩 Analysis chain🌐 Web query: 💡 Result: Sysinternals Handle.exe isn’t open-source, but its behavior matches the standard Windows “global handle table + duplicate + query” technique that Sysinternals has described historically (and that others reproduced by reverse-engineering older HandleEx/Handle drivers). What it does (high level)
The underlying Windows mechanisms it relies on1) Enumerating handles:
|
Contributor
|
Tip For best results, initiate chat on the files or code changes.
The good news: DWORD handleCount = 0;
HANDLE hProc = OpenProcess(PROCESS_QUERY_LIMITED_INFORMATION, FALSE, pid);
if (hProc) {
if (GetProcessHandleCount(hProc, &handleCount)) {
printf("Handle count: %lu\n", handleCount);
}
CloseHandle(hProc);
} else {
// Even limited query failed - protected process
printf("Handle count: Access denied\n");
}So your strategy could be:
This way users without admin still get useful info (the count), just not the full details! 🐰 🧠 Learnings used |
Owner
Author
|
@coderabbitai um... what? why are you saying "actually doesn't have a handle count field" well if it has count threads (as in the amount of threads the target process is using) that's good cuz the other program that's a version of witr is called witr-win. it's essentially my win-witr, it was made because there wasn't a version of witr for windows. witr-win does display the thread count. I haven't actually tried the original witr though, but apparently it doesn't give you the environment variables or handles for a process (that's what it says in the readme) so that's a plus that mine will have |
Contributor
|
Tip For best results, initiate chat on the files or code changes.
What I meant: You said "there is a function in the toolhelp32 api that gives you the count" - I thought you were referring to something in the BUT - there's a completely separate Win32 API function called So the fallback strategy is:
About thread count: Yeah, you already have thread count from About witr-win comparison: Nice! So your win-witr will have handles AND environment variables as a feature advantage over the original witr. The handle enumeration you're building (with fallback to just the count) will be a great addition! 🐰 Does this make more sense now? 🧠 Learnings used |
Owner
Author
|
@coderabbitai ah shoot yes i meant win32 api but yes whatever lol |
Contributor
|
Tip For best results, initiate chat on the files or code changes.
And Your handle enumeration strategy sounds solid - looking forward to seeing how it turns out! 🧠 Learnings used |
Owner
Author
|
@coderabbitai uh oh it hung |
Contributor
|
Tip For best results, initiate chat on the files or code changes. 🧩 Analysis chain🏁 Script executed: Length of output: 3319 🏁 Script executed: Length of output: 2525
The issue is at lines 1721-1740 where you call
The code already has one check ( The fix: Check the object type name first, then skip problematic types before querying the name: /* Query the object type. */
objectTypeInfo = (POBJECT_TYPE_INFORMATION)malloc(0x1000);
if (!NT_SUCCESS(pfnNtQueryObject(
dupHandle,
(OBJECT_INFORMATION_CLASS)ObjectTypeInformation,
objectTypeInfo,
0x1000,
NULL
)))
{
printf("[%#x] Error!\n", handle.Handle);
CloseHandle(dupHandle);
continue;
}
// Check for object types that are known to hang when querying name
WCHAR typeName[256];
wcsncpy_s(typeName, 256, objectTypeInfo->Name.Buffer, objectTypeInfo->Name.Length / 2);
typeName[objectTypeInfo->Name.Length / 2] = L'\0';
if (wcscmp(typeName, L"File") == 0 ||
wcscmp(typeName, L"ALPC Port") == 0 ||
wcscmp(typeName, L"IoCompletion") == 0 ||
wcscmp(typeName, L"TpWorkerFactory") == 0) {
/* These types can hang - just display the type without name */
printf(
"[%#x] %.*S: (name query skipped - type may hang)\n",
handle.Handle,
objectTypeInfo->Name.Length / 2,
objectTypeInfo->Name.Buffer
);
free(objectTypeInfo);
CloseHandle(dupHandle);
continue;
}
/* Query the object name (unless it has an access of
0x0012019f, on which NtQueryObject could hang. */
if (handle.GrantedAccess == 0x0012019f)
{
// ... rest of your codeThis will skip the hanging object types and keep things moving! You can adjust the skip list based on what you see. 🐰 🧠 Learnings used |
Owner
Author
|
@coderabbitai here's the full original stolen code that i stole the stolen code from btw |
Contributor
|
Tip For best results, initiate chat on the files or code changes.
Here's the thing: The original code has the exact same hang vulnerability that you're experiencing! The only difference is that whoever wrote/tested it probably ran it against processes that didn't happen to have the problematic handle types. What the original code does to prevent hangs:
Why this isn't enough:
About my DUPLICATE_SAME_ACCESS suggestion:
The original's simpler approach is totally valid, so you can revert to The real fix you need: /* Query the object type first */
objectTypeInfo = (POBJECT_TYPE_INFORMATION)malloc(0x1000);
if (!NT_SUCCESS(NtQueryObject(dupHandle, ObjectTypeInformation, objectTypeInfo, 0x1000, NULL))) {
printf("[%#x] Error!\n", handle.Handle);
CloseHandle(dupHandle);
continue;
}
/* Check if this type is known to hang on name queries */
WCHAR typeName[64];
wcsncpy_s(typeName, 64, objectTypeInfo->Name.Buffer, objectTypeInfo->Name.Length / 2);
typeName[objectTypeInfo->Name.Length / 2] = L'\0';
if (wcscmp(typeName, L"File") == 0 || wcscmp(typeName, L"ALPC Port") == 0) {
printf("[%#x] %.*S: (name query skipped)\n", handle.Handle,
objectTypeInfo->Name.Length / 2, objectTypeInfo->Name.Buffer);
free(objectTypeInfo);
CloseHandle(dupHandle);
continue;
}
/* NOW it's safe to query the name... */This way you avoid the hang entirely! 🐰 🧠 Learnings used |
Owner
Author
|
main.cpp(1705): error C2664: 'NTSTATUS (HANDLE,OBJECT_INFORMATION_CLASS,PVOID,ULONG,PULONG)': cannot convert argument 2 from 'int' to 'OBJECT_INFORMATION_CLASS' |
Contributor
|
Tip For best results, initiate chat on the files or code changes. 🧩 Analysis chain🏁 Script executed: Length of output: 367
if (!NT_SUCCESS(pfnNtQueryObject(dupHandle, ObjectTypeInformation, objectTypeInfo, 0x1000, NULL))) {To: if (!NT_SUCCESS(pfnNtQueryObject(dupHandle, (OBJECT_INFORMATION_CLASS)ObjectTypeInformation, objectTypeInfo, 0x1000, NULL))) {This is the same casting issue we dealt with earlier - MSVC requires explicit casts when passing integer constants to enum parameters. You'll need to do this for all your 🧠 Learnings used |
Owner
Author
|
@coderabbitai UGHH why are half of these unnamed or skipped 🙄 |
Contributor
|
Tip For best results, initiate chat on the files or code changes.
Why you're seeing these:1. "(unnamed)" handles - These are kernel objects that genuinely don't have names!
2. "(name query skipped)" handles - This is your anti-hang protection working correctly!
3. "Error!" handles - These are access denied scenarios
This is how Sysinternals Handle.exe works too!Looking at your output, you're actually getting great results:
Suggestions to make output more useful:Option 1: Filter to only show named objects if (objectName.Length == 0) {
continue; // Skip unnamed objects
}Option 2: Show summary statistics Option 3: Group by type This is genuinely working as intended! Windows processes have TONS of anonymous kernel objects. 🐰 🧠 Learnings used |
Owner
Author
|
@coderabbitai but at least sysinternals handle is actually useful because it actually shows the damn names of the file handles |
Contributor
|
Tip For best results, initiate chat on the files or code changes.
The ProblemNtQueryObject hangs on pipe handles opened for synchronous I/O with pending read operations, network file handles, and some console handles. But it works fine for regular file handles! Your current code skips ALL File handles, which is why you see "(name query skipped)" everywhere. The Solution: Worker Thread with TimeoutThe only solution is having a timeout on NtQueryObject. Here's how to implement it: // Structure to pass data to the worker thread
struct QueryObjectThreadData {
_NtQueryObject pfnNtQueryObject;
HANDLE handle;
PVOID buffer;
ULONG bufferSize;
NTSTATUS status;
HANDLE completedEvent;
};
// Worker thread function
DWORD WINAPI QueryObjectThreadProc(LPVOID param) {
QueryObjectThreadData* data = (QueryObjectThreadData*)param;
data->status = data->pfnNtQueryObject(
data->handle,
(OBJECT_INFORMATION_CLASS)ObjectNameInformation,
data->buffer,
data->bufferSize,
NULL
);
SetEvent(data->completedEvent);
return 0;
}
// Safe query with timeout
bool QueryObjectNameSafe(_NtQueryObject pfnNtQueryObject, HANDLE handle,
PVOID buffer, ULONG bufferSize, NTSTATUS* outStatus) {
QueryObjectThreadData threadData = {0};
threadData.pfnNtQueryObject = pfnNtQueryObject;
threadData.handle = handle;
threadData.buffer = buffer;
threadData.bufferSize = bufferSize;
threadData.completedEvent = CreateEvent(NULL, FALSE, FALSE, NULL);
HANDLE hThread = CreateThread(NULL, 0, QueryObjectThreadProc, &threadData, 0, NULL);
// Wait for 200ms
DWORD waitResult = WaitForSingleObject(threadData.completedEvent, 200);
if (waitResult == WAIT_TIMEOUT) {
// Hung! Kill the thread
TerminateThread(hThread, 1);
CloseHandle(hThread);
CloseHandle(threadData.completedEvent);
return false; // Timed out
}
*outStatus = threadData.status;
CloseHandle(hThread);
CloseHandle(threadData.completedEvent);
return true; // Success
}Then in your handle loop: // Instead of skipping all File handles:
if (wcscmp(typeName, L"File") == 0) {
NTSTATUS status;
if (!QueryObjectNameSafe(pfnNtQueryObject, dupHandle, objectNameInfo, 0x1000, &status)) {
printf("[%#x] File: (query timed out - likely pipe/network)\n", handle.Handle);
continue;
}
// Process the name...
}Important NotesThese threads can't be terminated safely and the IO operation can't be cancelled, so this process will leak threads equal to the number of blocked synchronous handles. But in practice, only a handful of handles hang, so you might leak 2-5 threads per run - totally acceptable for a diagnostic tool! Microsoft PowerToys offloads the faulty code to a distinct thread, which is killed on a timeout and the work is resumed with a new thread, and they confirmed this approach works for their users. This way you'll get names for 95% of File handles (regular files, DLLs, etc.) and only skip the problematic ones (pipes, network shares)! 🐰 🧠 Learnings used |
Owner
Author
|
@coderabbitai damn it it's not about the thread leak it's about the speed. i wanted win-witr to stay sub 70ms |
Owner
Author
|
per use |
Contributor
|
Tip For best results, initiate chat on the files or code changes.
Here's a much faster approach: Use // For File handles, use the documented Win32 API instead of NtQueryObject
if (wcscmp(typeName, L"File") == 0) {
WCHAR filePath[MAX_PATH * 2];
DWORD pathLen = GetFinalPathNameByHandleW(
dupHandle,
filePath,
sizeof(filePath) / sizeof(WCHAR),
FILE_NAME_NORMALIZED | VOLUME_NAME_DOS
);
if (pathLen > 0 && pathLen < sizeof(filePath) / sizeof(WCHAR)) {
printf("[%#x] File: %S\n", handle.Handle, filePath);
} else {
printf("[%#x] File: (access denied)\n", handle.Handle);
}
free(objectTypeInfo);
CloseHandle(dupHandle);
continue;
}
// For ALPC Port, skip entirely (always hangs)
if (wcscmp(typeName, L"ALPC Port") == 0) {
printf("[%#x] ALPC Port: (query skipped)\n", handle.Handle);
free(objectTypeInfo);
CloseHandle(dupHandle);
continue;
}
// For everything else, use NtQueryObject as normal...Why this is fast:
Tradeoff: Some File handles will show "access denied" if the duplicated handle doesn't have read attributes access, but that's way better than skipping them all! 🐰 🧠 Learnings used |
Owner
Author
|
@coderabbitai we can try the thread thing, but give them like 1 ms timeout let's see... |
Contributor
|
Tip For best results, initiate chat on the files or code changes.
// Structure to pass data to the worker thread
struct QueryObjectThreadData {
_NtQueryObject pfnNtQueryObject;
HANDLE handle;
PVOID buffer;
ULONG bufferSize;
NTSTATUS status;
volatile BOOL completed;
};
// Worker thread function
DWORD WINAPI QueryObjectThreadProc(LPVOID param) {
QueryObjectThreadData* data = (QueryObjectThreadData*)param;
data->status = data->pfnNtQueryObject(
data->handle,
(OBJECT_INFORMATION_CLASS)ObjectNameInformation,
data->buffer,
data->bufferSize,
NULL
);
data->completed = TRUE;
return 0;
}
// Safe query with 1ms timeout
bool QueryObjectNameSafe(_NtQueryObject pfnNtQueryObject, HANDLE handle,
PVOID buffer, ULONG bufferSize, NTSTATUS* outStatus) {
QueryObjectThreadData threadData = {0};
threadData.pfnNtQueryObject = pfnNtQueryObject;
threadData.handle = handle;
threadData.buffer = buffer;
threadData.bufferSize = bufferSize;
threadData.completed = FALSE;
HANDLE hThread = CreateThread(NULL, 0, QueryObjectThreadProc, &threadData, 0, NULL);
if (!hThread) return false;
// Wait for 1ms
DWORD waitResult = WaitForSingleObject(hThread, 1);
if (waitResult == WAIT_TIMEOUT) {
// Hung! Kill the thread (leaks the thread but keeps us fast)
TerminateThread(hThread, 1);
CloseHandle(hThread);
return false; // Timed out
}
*outStatus = threadData.status;
CloseHandle(hThread);
return true; // Success
}Then use it: // Try to query the name with 1ms timeout
NTSTATUS status;
if (!QueryObjectNameSafe(pfnNtQueryObject, dupHandle, objectNameInfo, 0x1000, &status)) {
// Timed out after 1ms - likely a blocking handle
printf("[%#x] %.*S: (query timed out)\n",
handle.Handle,
objectTypeInfo->Name.Length / 2,
objectTypeInfo->Name.Buffer);
free(objectTypeInfo);
CloseHandle(dupHandle);
continue;
}
if (!NT_SUCCESS(status)) {
// Query returned but failed
// ... handle error
}
Let's see how it performs! 🐰 🧠 Learnings used |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
this iss suuuper wip