Forum Widgets
Latest Discussions
RDCMan v3.21 crashing
Getting the following error System.NullReferenceException: Object reference not set to an instance of an object. at RDCMan.Nodes.Server.Dock() at RdcMan.ServerForm.OnClosed(EventArgs e) at System.Windows.Forms.Form.WmClose(Message& m) at System.Windows.Forms.Form.WndProc(Message& m) at RdcMan.RdcBaseForm.WndProc(Message& m) at System.Windows.Forms.NativeWindow.Callback(HWND hWnd, UInt32 msg, WPARAM wparam, LPARAM lparam) The error seems to happen when I have an undocked session, I restart the remote machine on the the undocked window, and it stays open, when I try to reconnect, on the same undocked window, it opens another docked session, I can login to the new session, and undock it, so now I have two undocked windows, the old one (disconnected) and the new one. I try to close the old one and I get the error shown below, (details above). If I click Continue, nothing happens, if I hit Quit, it closes RDCMan, as stated in the window.
RDCMan v3.21 failing to redirect drives
After updating to RDCMan v3.21 my RDP sessions no longer access my local drives. Steps to reproduce: Clear all settings, including Global settings (close all RDG files and rename %USERPROFILE%\AppData\Local\Microsoft\Remote Desktop Connection Manager\RDCMan.settings to "RDCMan.settings.old") Open RDCMan Create a new RDG file (e.g. File / New / "test.rdg") In the new RDG file, "Add [a new] server ..." On the "Logon Credentials" tab, enter your server's logon details On the "Local Resources" tab, be sure C:\ drive is selected for redirection Go to every tab and remove "Inherit from parent" Connect to the server In the RDP session, open File Explorer Observe that your C: drive is connected ("C on [client-machine-name]" is present) Logoff the server Save the RDG file ("File / Save All") Close RDCMan Re-open RDCMan - this should show the new RDG file with the server Re-connect to the configured server If you are prompted to trust the server's certificate, say "Connect Anyway" In the RDP session, open File Explorer OBSERVE THAT YOUR C: DRIVE IS NOT AVAILABLE No matter how I specify Local Resources (explicitly in the server properties, inherited from parent folder or global settings, etc.) after re-starting RDCMan, the drive is never made available. I have reproduced this consistently several times. MSTSC (Remote Desktop Connection) works every time (my drives are available in the RDP session) so this is not a group policy issue.Is this the right place to raise bugs? Even doc/help bugs?
Is this forum the right place to raise bugs observed in the Sysinternals tools, even doc/help bugs? I'm asking because I had raised one here 3 weeks ago, but there's been no reply or action indicated. I didn't think to prefix the subject with "BUG:", if that may be expected. And sadly the system here doesn't seem to let me edit a post once made. I'm also opting not to ask this as a comment on that post: even a simple "ping" would seemingly cause it to no longer appear in the "no replies yet" list--in case that's how some here keep an eye on things. :-) Is the bug critical? No. And since it's literally about the help ui, that may drop its priority still more--as it's not about functionality of the tool itself. But again is this even the right place to have pointed out the opportunity for improvement?Process Explorer 17.13 crashes on Windows Server 2012 R2
I know https://learn.microsoft.com/en-us/sysinternals/downloads/process-explorer says that Process Explorer v 17.13 runs on: Windows 11 and higher. Server: Windows Server 2016 and higher. I tried it on older server versions: Windows Server 2012 - runs fine Windows Server 2012 R2 - crashes at start with Log Name: Application Source: Application Error Event ID: 1000 Level: Error Description: Faulting application name: procexp64.exe, version: 17.13.0.0, time stamp: 0x6a7c29db Faulting module name: ntdll.dll, version: 6.3.9600.21620, time stamp: 0x65175333 Exception code: 0xc0000409 Fault offset: 0x0000000000080f18 Faulting process id: 0x21d0 Faulting application start time: 0x01dd30b89bb7c73b Faulting application path: ... Faulting module path: C:\Windows\SYSTEM32\ntdll.dll Ver. 17.06 runs fine on both Windows Server 2012 and 2012 R2. Is is possible to resolve this?help for rammap has seeming mistake
Folks, thanks for the wonderful tools. Here's what seems to be a minor issue (or two) that someone may want to address, about Rammap 1.63. When using rammap /?, the resulting help (popup) fails to correctly indicate run32 as the 3rd option that's clearly being discussed in the list below "usage", under the listed outputfile and inputfile arguments. I tried to share a screenshot here (captured from zoomit) but it would not be accepted. If you run the command, notice how the words "Launch the 32-bit..." start on the left, without indicating the name of the arg that's referring to. Finally, notice also the "usage" line itself: does it make sense that -o is followed by an input file name? Just trying to help, not complaining. :-)Process Monitor, a minor FYI / feedback / bug report
Big thanks to the Sysinternals team for the Process Monitor :-) that helps - I don't see why this is not a standard part of Windows :-) To the point: Apart from other things, Process Monitor can trace network socket API calls. I find this very useful right now, trying to troubleshoot a misbehaving proprietary app, where I do not know if it's the Windows Firewall dropping the incoming UDP packets, or the app itself. Well it seems that in my case it's the app, because I see the desired UDP responses coming in, in a packet sniffer (= before the firewall) and in Process Monitor (= at the sockets API level = after firewall). The app does get the response packet, and, apparently, ignores it :-) Further to the point: When tracing those UDP packets, i.e. send() and recv() API calls, Process Monitor helpfully displays the src and dst IP (or machine name) and UDP port numbers in the "Path" column (this is where filenames and directory paths normally appear, when tracing file access). And, when weaving the string for display, it apparently swaps the src and dst in recv()'ed packets, i.e. in the RX direction. I hope I'm interpreting this correctly. Just mu two cents worth. Thanks for your attention :-)
Bugs in RAMMAP and ZOOM it, Contig question/improvement
I use the latest versions of Sysinternals' RAMMAP, ZOOM-it and Contig. 1. RAMMAP still contains a bug. Start the program and open the "Process" tab. You will see that RAMMAP truncates the names of the processes to the 1st 14 characters of the process names. If the name of a process is e.g. 30 characters long (including the extension) then RAMMAP only displayes the 1st 14 characters and then the last 16 characters are not shown at all. I brought this bug to the attention of Microsoft in the past but this hasn't been fixed yet. 2. The latest versions of ZOOMit fail to start on my Windows 7 system. It then generates an error. Something along the lines of "Failed to start". This applies to both the 32 bit and 64 bit versions. Previous version of ZOOMit in the past did run & start on my system. 3. Is CONTIG able to defragment directory files themselves ? If so, then what should I type in MSDOS ? These can be fragmented as well. A program called DEFRAGGLER is capable to defrag directory files itself but not CONFIG !!! In Windows MS-DOS one can target the directory itself by using a dot ("."). E.g. "CD c:\windows\." This targets the directory itself. To be added to CONTIG as well in a future version.DebugView v. 5.0 freezes
It appears that if the file C:\Windows\MEMORY.DMP exists, DebugView/UI will freeze completely if permission to open/read the file hasn't been granted. DebugView is also incapable of telling what it's trying to do at the time (ie. trying to process a crash dump file). Running DebugView under a non-Administrative account & trying to process a renamed crash dump file yields the following error message:
