4

I have a WinForms (.NET C#) OLTP application based on Oracle.

From our support environment we regularly experience loss of connectivity to the database, and a resulting minidump file is generated (by what, i am not entirely certain of) - apparently it does not cause the application to crash, but in order to actually do anything you have to close it and start it again.

After a many such minidumps have been created in the same directory, all of a sudden the minidumps starts getting rather strange file names, filenames that are apparently "illegal" on windows.

For instance we have a file name like:

"°÷ƒ _minidump_default_pid_20248_tid_x19AC_2015_9_1_8_31_51.dmp"

And yes the carriage return is PART of the file name.

We discovered this because log4net watches the directory and all of a sudden starts to bark unhandled exceptiosn due to these invalid file names.

So we are trying to figure out why the minidump is generated in the first place, but the question here is, can we somehow prevent the minidump from being generated with an invalid filename or otherwise control the naming process?

Secondly, does anybody know why is it even possible to create invalid file names in the first place?

Update: For anyone looking at this trying to figure out why the dump files are created in the first place, our issue was that Windows was generating them when it was near running out of memory, but for some reason we would'nt always get an OOMException.

Uwe Keim
  • 39,551
  • 56
  • 175
  • 291
Esben Bach
  • 664
  • 4
  • 23

2 Answers2

1

First, you should really try to find out how those dumps are generated. Microsoft e.g. provides a nice way using a Registry key called LocalDumps which has provided great help for me. I am sure that this approach won't generate invalid file names like above.

Second, if the application does not crash, it has probably registered an unhandled exception handler. This is basically ok and designed to write crash dumps, but the unhandled exception is handled by the crashing process itself. How can the code to handle the situation be sure he himself is not affected by the crash? The better option is to let Windows as the OS handle the crash. Then the Windows kernel (which is not affected by the crash) can really handle the situation. That's what LocalDumps does.

Third, direct file system access is possible in Windows via paths that start with \\.\ when passing it to the Windows API. Starting a path like that will skip any file name check so you can generate files with reserved characters such as *, ?, : or newlines as observed by you. The unhandled exception handler of your application is probably doing that and is affected by the crash in a way that parts of the file name are overwritten.

Chkdsk should be able to repair the file system.

Thomas Weller
  • 55,411
  • 20
  • 125
  • 222
  • 1
    The "funny" thing is that my unhandled exception handler is not generating the dumps. Its basically just displaying the exception (along with the stack trace) in a messagebox + logging the exception to log4net. Addtionally, it seems the application is not crashing after it so it is not a "fatal" exception like an StackOverflowException or some such. We will have a look at changing the LocalDumps location and see if the same thing happens. – Esben Bach Sep 07 '15 at 07:04
  • Still trying to figure out what exactly is causing the minidumps to be generated (since its not our code), but configuring the registry key as desribed in the link seems to have fixed the invalid filename generation issue. – Esben Bach Sep 09 '15 at 07:27
-1

pls check if you are installing from network path like \remoteserver\d$\client.

then change it to \remoteserver\d\clinet

"$" in share path create issue while extration on elevated permission files

B S Vivekananda
  • 1
  • The question is already answered, its rather old and your comment does not really address the question in any way that seems related. – Esben Bach Aug 19 '21 at 08:51