Marc Sherman

Which #dbgeng interface to use? For example, both IDebugSymbols2 and IDebugSymbols3 implement GetModuleNameString(). Should I use I2 to support older OS versions or I3 for a possibly improved implementation? #windbg

I'm glad more people are realizing this.

@ExtinguishedEng awesome!

AI has triggered a shift in our relationship with Product. Management expected amazing results with AI and didn't see them. Now we're telling our Engineering VPs what amazing things we could do if only Product and UX weren't in the way, and they're telling us to go for it. We take an idea, plan it, and execute. The results are awesome. I'm building great stuff with no tickets. I maintain my own checklist and mark off a few things every day. Our Product Owner has disappeared from sight. We're doing our best work without him. Whatever his place is, we don't need him slowing us down by breaking up our work into weird technical tasks he doesn't understand. We're sprinting.

In general, if you need to change a test because you changed the code, you didn't have a test at all. The whole _point_ of a test is that, when I make a change, I want to run the test to see if I've broken anything. A good test works both before and after the change. If I have to change the test, too, I've proven nothing. Any test that knows how the code works (as compared to what the code does) is fundamentally flawed. I hear a lot about using an LLM not only to write code but also to write tests. I've rarely seen that work. IME, the LLM-generated tests are too fragile and test the wrong things (the implementation, not the intent). People talk about spec-driven design, but the best spec you can have is a test—a test you write before you write the code. You don't write a test to see if the code adheres to a spec. The test IS the spec. Don't write specs. Write tests.

Custom frameworks: > I designed a new utensil for eating. It looks like a weird spoon. I don't need it. I have utensils. > I put a lot of work into it, so you need to eat with it. I'm trying to eat spaghetti. I can't pick up spaghetti with your weird spoon. [three days later] > I modified it so you can attach a fork to it. Now it works. Be sure to use my new utensil. I can't cut my steak with it. > Well you shouldn't be eating steak. That's your problem. If you stop eating steak my utensil won't have any problems. Ok, fine. But I can't cut this healthy baked potato with it. > Look, I'm busy. Working on this utensil isn't all I do. You need to pitch in and figure out how to modify it to do what you want. I'll just use my old utensils. > We can't have everyone using different utensils. New people who eat with us will be confused. That's why we're standardizing on my new one. Fine. [one week later] >> Who changed the utensil? Last week I was using it to eat soup, but now the potato-cutting part pokes me in the face. > I'm starting over on Utensil 3.0. It's going to automate all of that. When it's almost done I'll record a video showing how to work it. Everyone set aside time to switch over.

@ExtinguishedEng @allenholub 😂

@allenholub Our architecture doesn't solve problems we don't have. It creates them.

In my experience, the vast majority of waste in a software shop is time spent building things nobody wants on top of overly complex architectures that solve problems we don't have. Focus on that. Put solving your customer's actual (not imagined) problems first. And do exactly that—no bells and whistles; no futureproofing (select a change-friendly architecture instead). Forcing AI onto a customer who doesn't want it (because it doesn't solve a real or critical problem for them) is worse than waste. It drives people away. Sitting around imagining how AI can "help" your customers without understanding their specific problems is just expensive arrogance.

A statement from Anthropic CEO, Dario Amodei, on our discussions with the Department of War. anthropic.com/news/statement…

@wmessmer Oh, I forgot to ask, what is an EE? Is it a calculated expression for the length? Thanks!

@msherman1970 -c N just skips the first N elements from the iterator in displaying. If you put a format specifier after the expression with the number of elements you want, you'll get that. Works like VS. "dx container, 1000" will give 1000. "dx container, [expression]" allows an EE.

How to stop the #windbg dx command from only showing 0x63 elements at a time along with […]? I tried ‘-c 1000’ and nothing was displayed. I tried ‘-c 1’ and ‘-c 0’ and the behavior was the same as not specifying ‘-c’ at all.

@wmessmer That worked, thanks!!

"Writing code is no longer the bottleneck" is how AI fans tell their bosses "it's okay now, I chased the monster out from under the bed and he won't be back." A total lie, but one that they can hear instead of the truth: that it never was.

Oh wow, appending ‘.Where(p => p.Count())’ did the trick. But what the heck is being counted? The number of threads that satisfied the where clause?

How can I get this #windbg LINQ command to return only processes with a suspended thread? As is, it returns empty process objects for those without suspended threads: dx -r2 @$cursession.Processes.Select(p => p.Threads.Where(t => t.KernelObject.Tcb.SuspendSchedulerApcWait != 0))

In honor of today's 25th anniversary of the Agile Manifesto, I'd like to remind everybody that the very first sentence starts with: "We are uncovering better ways of developing software by doing it…" The critical word in that sentence is "uncovering." They didn't say "uncovered," which would mean there's no more work to do. Instead, they are talking about an active and ongoing activity: uncovering. Nowhere in the Manifesto does it tell you *how* to work. There are no sprints, backlogs, standups (or any other meeting), SMs, POs, PBIs, tickets, or any of the other barnacles that have accreted over time, often added by people with suspect agendas (like selling certificates). The one exception is: "the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly." We are constantly improving how we work ("uncovering"), which, to me, suggests that we add, remove, and change things, and we make those changes based on observation and assessment. This attitude is particularly important when a radical new tool, such as an LLM, emerges. We improve "by doing it." We use the new thing, then decide based on our experience. We don't just sit back and say it doesn't work because it's not what we're doing now, or because some moron has hyped it too much. Agility is scary. It requires constant personal experimentation with new ways of working. Some of those things work, some don't, but you don't know until you try. The next important word is "ways," plural. I've never seen any good come from everyone marching in lockstep to a specific process or framework. At best, that uniformity adds friction. At worst, it adds dysfunction. Every team, every story, every situation, is unique and requires unique ways of working. Create a set of values and principles, and as long as people adhere to those, you're golden. The people who do the work are in the best position to figure out how to do the work. Of course, control-obsessed people high up in an organization hate that because they can't control it. They call it "chaos." Replacing control for trust is an essential element of becoming "Agile," however. Finally, the end of that initial sentence is "…and helping others do it." We improve as a community through collaboration and communication. That can be fraught. E.g., the #NoEstimates tag began when Woody Zuill posted that his team had just finished a successful project without estimates. Instead of "that's interesting, tell me more," the reactions were often hateful attacks that came down to "It's not possible to work without estimates, so you're an incompetent, irresponsible liar." But it _did_ work. That was the whole point. Working is the starting point of the discussion. Try it and then comment. Experimentation fills in the details. That's how you learn and improve. That's Agile.

@kmcnam1 @guyrleech 😂

@33y0re Thank you!! Followup question: Why do both ‘@$myThread->’ and ‘@$myThread.’ work when calling ToDisplayString? It seems that @$myThread is both a pointer and an object.

@msherman1970 To get the address of an object, use C-style syntax dx -r0 &@$curthread.KernelObject. See below the differences. This output could then be stored in a variable and passed to the .thread commend for example.

In the #windbg data model, I can get a thread’s _ETHREAD via ‘dx @$curthread.KernelObject’. But how can ‘dx’ be used to get the address of the _ETHREAD so that I can pass it to the older ‘.thread’ command?

@gregrthenson @DanielW_Kiwi 😂

@DanielW_Kiwi I always called my kids "my fleshy kettlebells" Then they got older and they lost that functionality Now they're just a tool for strengthening my patience XD

Doing skull crushers with a three year old as the weight is harder than I expected

@ExtinguishedEng 😂

"Good devs don't use their mouse. They use the keyboard because it's faster." I'm sincerely happy that it works out for you. Where exactly do you think my mouse is? Do you think I walk across the building to move my mouse and then drag the cursor from Bangladesh?

@pikuma 😂

I hope this explains the reason why I'm okay with showing my face in my videos...