Advice on Debugging Technique Needed

Sonhospa

Hi all, I want to debug an external tool (call it "X") in order to find the source of some strange behaviour: X does what it's supposed to do, i.e. generates a file in a special format, only if the international system settings are set to English (Decimal dot character). Using e.g. European international settings, there's a file with zero length resulting. Being more like a hobby programmer, I don't have any idea where and how to start debugging... Can someone please guide me to a useful technique? Thank you in advance, Mick

Mycroft Holmes

What is your expectation here. You can't modify the tool so debugging is a waste of time. You can't debug a DLL unless you are supplied with the symbols file or the source code. Basically you need to either go back to the supplier of the tool or reverse engineer the tool and internationalise it.

Never underestimate the power of human stupidity RAH

Sonhospa

Thank you for giving me the question about my expectation back :laugh: Should have answered that to myself before asking. Meanwhile, I tried to reverse engineer the tool (dotpeek). Unfortunately, after exporting a C# project from that, there are some errors remaining - mostly it seems there are only "break" commands missing. But if I "correct" these errors with my limited knowledge, the resulting exe (testwise used instead of the original) throws many runtime errors - so obviously my "correction" isn't proper. So it seems I'm stuck despite of the reverse engineering. Regards - Mick

Lost User

Maybe a different file is winding up somewhere in a different folder. Scan for "date last modified / created" files based on your "experiments".

Lost User

Try ILSpy. If it is a .NET assembly, you could generate a single C# file from it. That is something one could edit, and recompile. That is, if such thing is allowed under the current license :)

Bastard Programmer from Hell :suss: If you can't read my code, try converting it here[^][](X-Clacks-Overhead: GNU Terry Pratchett)

Sonhospa

Thank you, Eddy. Tried ILSpy and saved the C# project, just as I did with dotpeek before. Of course, the biggest part of the code - from both the tools - is readable. While the project saved from dotpeek left me with approx. 15 errors, ILSpy leaves me with 56 of them. I made a workaround now: Before using the tool (i.e. start process) I write the needed strings to the registry (e.g. decimal dot) and restore the defaults after compilation. I'm not a professional programmer like many of you, so I better don't mess with reengineered code that I don't fully understand. And nearby I don't have to get any blame for license issues :laugh: Thank you, though!

Sonhospa

That's not the case, Gerry. Both the tools write a project into their proper folders. But I found a workaround now, pls see my last answer above if you're intrested. Regards - Mick

Lost User

Personally, I'd rather play with my own shiny new code, than hack / crack someone else's "old" code. :-D

Alan N

A .NET application may be executed within a separate AppDomain of an existing process and the application will use the culture associated with the thread. This may allow you to run your tool "X" without editing the registry. At it's simplest it just this: (compile as a Windows Application)

using System;
using System.Globalization;
using System.Threading;

namespace SpoofCulture {
internal sealed class App2 {
// Your apps full path here
private const String TrialApp = @"E:\VC\Projects\AppDomainExec\Apps\TestApp.exe";
// Your desired culture here
private const String AppCulture = "fr-FR";
//private const String AppCulture = "de-DE";

\[STAThread\]
private static void Main() {
  // Change the culture
  Thread.CurrentThread.CurrentCulture = CultureInfo.GetCultureInfo(AppCulture);
  AppDomain newDomain = AppDomain.CreateDomain("HostingDomain");
  newDomain.ExecuteAssembly(TrialApp);
  AppDomain.Unload(newDomain);
}

}
}

My TestApp.exe displays some culture dependent text, DateTime.Now.ToLongDateString() e.g.

mercredi 23 mars 2016 when culture is fr-FR
Mittwoch, 23. März 2016 de-DE

Alan.

Sonhospa

Hi Alan, thank you for the idea. Actually, before writing to the registry, I looked for a way how to have a process ("process.start()") run in a particular culture... Couldn't find information on that, so the registry hack was my problem solver. Now I tried your code, but unfortunately I encounter a strange effect: The called tool starts executing, it also consumes my additional parameters (as I can see from the Console messages), but ... then it seems to stop on it's half way, the Console window stays open and nothing goes on anymore. This is different from my older experiments with "process.start()": Once the parameters (path etc.) were fed correctly, the tool just worked (with different results depending on the system culture setting). I have no idea what mightbe wrong now.

Sonhospa

Hi Alan, thank you for the idea. Actually, before writing to the registry, I looked for a way how to have a process ("process.start()") run in a particular culture... Couldn't find information on that, so the registry hack was my problem solver. Now I tried your code, but unfortunately I encounter a strange effect: The called tool starts executing, it also consumes my additional parameters (as I can see from the Console messages), but ... then it seems to stop on it's half way, the Console window stays open and nothing goes on anymore. This is different from my older experiments with "process.start()": Once the parameters (path etc.) were fed correctly, the tool just worked (with different results depending on the system culture setting). I have no idea what mightbe wrong now. Salut Mick